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

[Danny Thorpe]

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

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

Thanks,
-Danny

On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd  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

[Danny Thorpe]

FWIW, The Open Assets colored coin protocol (CoinPrism) places special
significance on the zeroth input and the position of the OP_RETURN colored
coin marker output to distinguish colored coin issuance outputs from
transfer outputs. Reordering the inputs or the outputs breaks the colored
coin representation.

Recommending sorting of the inputs and outputs as a best practice is fine
(and better than random, IMO), but not as part of IsStandard() or consensus
rules.  There are cases where the order of the inputs and outputs is
significant.

-Danny

On Fri, Jun 5, 2015 at 9:42 PM, Rusty Russell  wrote:

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

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

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

Thanks,
-Danny

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

> 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
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

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

Thanks,
-Danny

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

> Summary
> ---
>
> 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.
>
> without:
>
> 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.
>
>
> Semantics
> -
>
> 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)
>
>
> Implementation
> --
>
> Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176
>
> A backport to v0.10.2 is pending.
>
> An implementation of fee bumping respecting FSS rules is available at:
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py
>
>
> 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
>   output.
>
>
> 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%

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

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

Thanks,
-Danny

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
>
> --
> 'peter'[:-1]@petertodd.org
> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>
>
> --
> 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-d

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

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

-Danny

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; Blockchain.info; 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.
> 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] Bitcoin transaction

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

https://github.com/OpenAssets/open-assets-protocol

http://www.CoinPrism.com also has a discussion forum where some colored
coin devs hang out.

http://www.coinprism.info is a blockchain explorer that is colored-coin
aware.

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

> 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) <
> patrick.mcco...@newcastle.ac.uk>:
>
>>  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 [mailto:lemienteleph...@gmail.com]
>> *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.
>>
>> Thanks
>>
>
>
>
> --
> 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