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

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

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


On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd wrote:

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

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

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

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

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



 Bitcoin-development mailing list

Bitcoin-development mailing list

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

2015-05-26 Thread Danny Thorpe
What prevents RBF from being used for fraudulent payment reversals?

Pay 1BTC to Alice for hard goods, then after you receive the goods
broadcast a double spend of that transaction to pay Alice nothing? Your
only cost is the higher network fee of the 2nd tx.


On Mon, May 25, 2015 at 5:10 PM, 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.;117567292;y
 Bitcoin-development mailing list

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.;117567292;y___
Bitcoin-development mailing list

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Danny Thorpe
Apologies if this has already been stated and I missed it, but:

Can transactions in a buried block be overridden/replaced by RBF?

Or is RBF strictly limited to transactions that have not yet been
incorporated into a block?


On Mon, May 25, 2015 at 10:13 PM, Peter Todd wrote:


 First-seen-safe replace-by-fee (FSS RBF) does the following:

 1) Give users effective ways of getting stuck transactions unstuck.
 2) Use blockchain space efficiently.


 3) Changing the status quo with regard to zeroconf.

 The current Bitcoin Core implementation has first-seen mempool
 behavior. Once transaction t1 has been accepted, the transaction is
 never removed from the mempool until mined, or double-spent by a
 transaction in a block. The author's previously proposed replace-by-fee
 replaced this behavior with simply accepting the transaction paying the
 highest fee.

 FSS RBF is a compromise between these two behaviors. Transactions may be
 replaced by higher-fee paying transactions, provided that all outputs in
 the previous transaction are still paid by the replacement. While not as
 general as standard RBF, and with higher costs than standard RBF, this
 still allows fees on transaction to be increased after the fact with
 less cost and higher efficiency than child-pays-for-parent in many
 common situations; in some situations CPFP is unusable, leaving RBF as
 the only option.


 For reference, standard replace-by-fee has the following criteria for
 determining whether to replace a transaction.

 1) t2 pays  fees than t1

 2) The delta fees pay by t2, t2.fee - t1.fee, are = the minimum fee
required to relay t2. (t2.size * min_fee_per_kb)

 3) t2 pays more fees/kb than t1

 FSS RBF adds the following additional criteria to replace-by-fee before
 allowing a transaction t1 to be replaced with t2:

 1) All outputs of t1 exist in t2 and pay = the value in t1.

 2) All outputs of t1 are unspent.

 3) The order of outputs in t2 is the same as in t1 with additional new
outputs at the end of the output list.

 4) t2 only conflicts with a single transaction, t1

 5) t2 does not spend any outputs of t1 (which would make it an invalid
transaction, impossible to mine)

 These additional criteria respect the existing first-seen behavior of
 the Bitcoin Core mempool implementation, such that once an address is
 payed some amount of BTC, all subsequent replacement transactions will
 pay an equal or greater amount. In short, FSS-RBF is zeroconf safe and
 has no affect on the ability of attackers to doublespend. (beyond of
 course the fact that any changes what-so-ever to mempool behavior are
 potential zeroconf doublespend vulnerabilities)


 Pull-req for git HEAD:

 A backport to v0.10.2 is pending.

 An implementation of fee bumping respecting FSS rules is available at:

 Usage Scenarios

 Case 1: Increasing the fee on a single tx

 We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
 with the minimal relay fee, 2.26uBTC. Increasing the fee while
 respecting FSS-RBF rules requires the addition of one more txin, with
 the change output value increased appropriately, resulting in
 transaction t2, size 374 bytes. If the change txout is sufficient for
 the fee increase, increasing the fee via CPFP requires a second
 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
 input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
 of 566 bytes.

 Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
   cases where the original transaction didn't have a change

 Case 2: Paying multiple recipients in succession

 We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice.
 We now need to pay Bob. With plain RBF we'd just add a new outptu and
 reduce the value of the change address, a 90% savings. However with FSS
 RBF, decreasing the value is not allowed, so we have to add an input.

 If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can
 be created, 2*226=452 bytes in total. With FSS RBF we can replace t1
 with a 2-in-3-out tx paying both, increasing the value of the change
 output appropriately, resulting in 408 bytes transaction saving 10%

 Similar to the above example in the case where the change address of t1
 is insufficient to pay Bob the end result is one less transaction output
 in the wallet, defragmenting it. Spending these outputs later on would
 require two 148 byte inputs compared to one with RBF, resulting in an
 overall savings of 25%

 Case 3: Paying the same recipient multiple times


Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Danny Thorpe
Thanks for the clarification.

So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.

The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.

So an implementation that wishes to take advantage of RBF will still need
to have a plan B implementation path to handle the corner case of a
replacement tx being rejected as a double spend.

Is this correct?

I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.


On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille

 It's just a mempool policy rule.

 Allowing the contents of blocks to change (other than by mining a
 competing chain) would be pretty much the largest possible change to
 Bitcoin's design

Bitcoin-development mailing list

Re: [Bitcoin-development] Bitcoin transaction

2015-05-12 Thread Danny Thorpe
See the Open Assets protocol specification for technical details on how a
colored coin (of the Open Asset flavor) is represented in a bitcoin
transaction. also has a discussion forum where some colored
coin devs hang out. is a blockchain explorer that is colored-coin

On Tue, May 12, 2015 at 2:54 AM, Telephone Lemien

 Thank You,
 I know this, but I want to have mores details in the inputs/outputs, or in
 the script of input/output and how i will proceed in the code.
 Thanks for all replaying

 2015-05-12 11:47 GMT+02:00 Patrick Mccorry (PGR)

  There is no difference to the transaction as far as im aware – just the
 inputs / outputs have a special meaning (and should have a special order).
 So you can track 1 BTC throughout the blockchain and this 1 BTC represents
 my asset. Someone may give a more useful answer.

 *From:* Telephone Lemien []
 *Sent:* 12 May 2015 10:45
 *To:* Bitcoin Dev
 *Subject:* [Bitcoin-development] Bitcoin transaction

 Hello evry body,

 I want to know what is the difference between a bitcoin transaction and
 colored coins transaction technically.


 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.;117567292;y
 Bitcoin-development mailing list

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.;117567292;y___
Bitcoin-development mailing list

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-12 Thread Danny Thorpe
Having thousands of utxos floating around for a single address is clearly a
bad thing - it creates a lot of memory load on bitcoin nodes.

However, having only one utxo for an address is also a bad thing, for
concurrent operations.

Having several utxos available to spend is good for parallelism, so that
2 or more tasks which are spending from the same address don't have to line
up single file waiting for one of the tasks to publish a tx first so that
the next task can spend the (unconfirmed) change output of the first.
Requiring/Forcing/Having a single output carry the entire balance of an
address does not work at scale. (Yes, this presumes that the tasks are
coordinated so that they don't attempt to spend the same outputs. Internal
coordination is solvable.)

In multiple replies, you push for having all utxos of an address spent in
one transaction.  Why all?  If the objective is to reduce the size of the
utxo pool, it would be sufficient simply to recommend that wallets and
other spenders consume more utxos than they create, on average.

I'm ok with consume more utxos than you generate as a good citizen / best
practices recommendation, but a requirement that all prior outputs must be
spent in one transaction seems excessive and impractical.


On Sat, May 9, 2015 at 10:09 AM, Jim Phillips wrote:

 Forgive me if this idea has been suggested before, but I made this
 suggestion on reddit and I got some feedback recommending I also bring it
 to this list -- so here goes.

 I wonder if there isn't perhaps a simpler way of dealing with UTXO growth.
 What if, rather than deal with the issue at the protocol level, we deal
 with it at the source of the problem -- the wallets. Right now, the typical
 wallet selects only the minimum number of unspent outputs when building a
 transaction. The goal is to keep the transaction size to a minimum so that
 the fee stays low. Consequently, lots of unspent outputs just don't get
 used, and are left lying around until some point in the future.

 What if we started designing wallets to consolidate unspent outputs? When
 selecting unspent outputs for a transaction, rather than choosing just the
 minimum number from a particular address, why not select them ALL? Take all
 of the UTXOs from a particular address or wallet, send however much needs
 to be spent to the payee, and send the rest back to the same address or a
 change address as a single output? Through this method, we should wind up
 shrinking the UTXO database over time rather than growing it with each
 transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database
 will grow, simply because there are 7 billion people in the world, and
 eventually a good percentage of them will have one or more wallets with
 spendable bitcoin. But this idea could limit the growth at least.

 The vast majority of users are running one of a handful of different
 wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase;
 Circle;; and maybe a few others. The developers of all
 these wallets have a vested interest in the continued usefulness of
 Bitcoin, and so should not be opposed to changing their UTXO selection
 algorithms to one that reduces the UTXO database instead of growing it.

 From the miners perspective, even though these types of transactions would
 be larger, the fee could stay low. Miners actually benefit from them in
 that it reduces the amount of storage they need to dedicate to holding the
 UTXO. So miners are incentivized to mine these types of transactions with a
 higher priority despite a low fee.

 Relays could also get in on the action and enforce this type of behavior
 by refusing to relay or deprioritizing the relay of transactions that don't
 use all of the available UTXOs from the addresses used as inputs. Relays
 are not only the ones who benefit the most from a reduction of the UTXO
 database, they're also in the best position to promote good behavior.

 *James G. Phillips IV*

 *Don't bunt. Aim out of the ball park. Aim for the company of immortals.
 -- David Ogilvy*

  *This message was created with 100% recycled electrons. Please think
 twice before printing.*

 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.;117567292;y
 Bitcoin-development mailing list

One dashboard for servers and applications