Re: [Bitcoin-development] Scaling Bitcoin with Subchains
On Wed, May 27, 2015 at 9:16 PM, Andrew wrote: > You should also keep in mind the big picture when it comes to > decentralization. If the hard drives (or tapes) can only be produced by a > small number of large companies like Western Digital or Seagate, then you > can't really count those for a decentralized system. A truly decentralized > system would have the devices needed to participate in (and verify) the > system be easily created by a regular user of the system without relying on > a central power. So for example, the hard drives needed to store the > bitcoin transaction records should be able to be produced at a regular > person's home on a 3D printer starting from just the raw materials. I don't > know how close we are to this ideal, but just pointing out that it needs to > be considered. This is also a reason why I like that Bitcoin uses the > simple SHA sum for mining instead of a more complicated function such as > scrypt. It makes it easier for small scale entities to understand and to > produce the ASIC miners. I am a huge fan of do-it-yourself at-home ASIC manufacturing. The original 4004 and earlier devices are within the scope of what could be accomplished in a home environment. The homecmos project is an interesting glimpse at these possibilities. Relevant-scale mining will most likely never be an option for home manufacturing, but bitcoin wallets and other devices can definitely be etched by hand or using maskless projector lithography. Here's what the homecmos group was up to: https://code.google.com/p/homecmos/ http://homecmos.drawersteak.com/wiki/ http://diyhpl.us/~bryan/papers2/optics/photolithography/DIY%20fabrication%20of%20microstructures%20by%20projection%20photolithography.pdf LCD projection lithography: http://diyhpl.us/~bryan/papers2/optics/photolithography/Cell%20micropatterning%20using%20photopolymerization%20with%20a%20liquid%20crystal%20device%20(LCD)%20commercial%20projector%20-%20Itoga%20-%202003.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/Development%20of%20microfabrication%20technology%20with%20maskless%20photolithography%20device%20using%20LCD%20projector%20-%20Itoga%20-%202010.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/Second-generation%20maskless%20photolithography%20device%20for%20surface%20micropatterning%20and%20microfluidic%20channel%20fabrication%20(using%20an%20LCD%20projector).pdf DMD lithography: http://diyhpl.us/~bryan/papers2/optics/photolithography/Maskless%20microscopic%20lithography%20through%20shaping%20ultraviolet%20(UV)%20laser%20with%20digital%20micromirror%20device%20(DMD)%20-%202013.pdf http://diyhpl.us/~bryan/papers2/optics/photolithography/A%20maskless%20photolithographic%20prototyping%20system%20using%20a%20low-cost%20consumer%20projector%20and%20a%20microscope.pdf There's actually a method of doing this with conventional camera roll film: https://groups.google.com/d/msg/diybio/5hpQXZ6hFKY/baGNfY_-Wx8J - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scaling Bitcoin with Subchains
Hi All
I discussed this idea with some other core developers (on IRC) and they
generally seem to agree that it can be done.
It may be equivalent to an idea called "blockchain extensions" but when I
looked it up on bitcointalk.org I didn't see exactly the same proposal I am
making.
One person suggested I should replace the address to chain function with a
protocol addition that allows one to specify the target chain. Yes, this
can also be done without changing the key properties.
One person said that the main problem is that I am not saying anything
specific, and I should address the sidechain problems written about in the
sidechains paper. Well, actually, there is one quite specific thing I am
saying, in case you didn't notice: With this system, the network can
achieve effectively 5^{n-1} MB blocks with each participant only storing n
MB blocks. So for example, you can have effectively a block size of 625 MB
(= 5^4) with each participant only storing 3 MB blocks; or 3.125 GB blocks
with each participant only storing 4 MB blocks. For these calculations, I
am assuming that only two separate sibling chains are involved in a
transaction, so there is a duplication effect that divides in two the
effective size of a given level of blocks (that's why it's 5 instead of 10
as would be without duplication). If you want to involve multiple sibling
chains in one transaction, you can effectively achieve this by performing
multiple transactions involving 2 of the multiple chains. Yes, the fees
would be higher since you have more transactions to make, but it is
reasonable to expect more fees for more complicated transactions, and I
don't think it will result in people clustering on one chain (people who do
these kinds of transactions would probably track multiple chain paths). As
for the problems with sidechains, I think they would be eliminated due to
the child-parent dependence I specified. I also propose the following
additional rule: In case of conflict between parent and child chains (due
to reorganizations), the child chain must choose the consensus of the
parent chain. Also, for transferring from child to parent, the miners on
the parent have the final say, but to make it more clear, they can use the
relative difference of difficulty between their chain and the child chain
to decide how many blocks deep a transaction in the child chain has to be
to be accepted in the parent chain.
Gavin was the only one who disapproved of this, but I am not sure if he
actually read the whole thing that I wrote. He said something along the
line of "the outputs will span the subchains" and when I asked for an
explanation he just said that I need to learn more about things. I stated
to him my willingness to learn, but have yet to get a response from him.
Mike: You should also keep in mind the big picture when it comes to
decentralization. If the hard drives (or tapes) can only be produced by a
small number of large companies like Western Digital or Seagate, then you
can't really count those for a decentralized system. A truly decentralized
system would have the devices needed to participate in (and verify) the
system be easily created by a regular user of the system without relying on
a central power. So for example, the hard drives needed to store the
bitcoin transaction records should be able to be produced at a regular
person's home on a 3D printer starting from just the raw materials. I don't
know how close we are to this ideal, but just pointing out that it needs to
be considered. This is also a reason why I like that Bitcoin uses the
simple SHA sum for mining instead of a more complicated function such as
scrypt. It makes it easier for small scale entities to understand and to
produce the ASIC miners. Also, in addition to the centralization of storage
device manufacturing, one should also consider what would happen if
everyone wanted to have a 5 TB drive at home. What would happen to the
price of hard drives? Keep in mind also that the human population is likely
increasing, so there are less real resources per person... Yes maybe in the
future we can solve these problems, but we still haven't, so let's not
assume they are solved. Also, you mentioned sharing the costs of a hard
drive with other people. Do you mean trusting that others did not
compromise the hard drives? If you want you can do so, but not every
participant should be forced to trust others, a point I think I made
already. And finally, this is all a discussion on the costs of running a
Bitcoin node. Bitcoin is not all that people will use hard drives and
computers for; we need to leave room for other things.
So Mike, I have a question for you. Are you supporting a block size
increase partly due to philosophical reasons (i.e. you believe that regular
people shouldn't have such strong freedom as I want) or do you just not
care so much about the long term future and you just want to get your
Bitcoin related projects up and running with minimal complications? Or
Re: [Bitcoin-development] Version bits proposal
There is absolutely no reason to do this. Any reasonable micro-controller can build merkle tree roots significantly faster than is necessary. 1 Th/s walks the nonce range once every 4.3ms. The largest valid merkle trees are 14 nodes high. That translates to 28 SHA256 ops per 4.3ms or 6511 SHA256 ops/second. For reference an RPi 1 model B does 2451050 SHA256 ops/second. On 05/27/2015 03:52 PM, Sergio Lerner wrote: > I like the idea but I think we should leave at least 16 bits of the > version fixed as an extra-nonce. > If we don't then miners may use them as a nonce anyway, and mess with > the soft-fork voting system. > My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102 > > Best regards > > > -- > ___ > 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] Version bits proposal
I like the idea but I think we should leave at least 16 bits of the version fixed as an extra-nonce. If we don't then miners may use them as a nonce anyway, and mess with the soft-fork voting system. My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102 Best regards -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn wrote: > I wrote an article that explains the hashing assurance contract concept: > > https://medium.com/@octskyward/hashing-7d04a887acc8 > > (it doesn't contain an in depth protocol description) The prior (and seemingly this) assurance contract proposals pay the miners who mines a chain supportive of your interests and miners whom mine against your interests identically. There is already a mechanism built into Bitcoin for paying for security which doesn't have this problem, and which mitigates the common action problem of people just sitting around for other people to pay for security: transaction fees. Fixing the problem with assurance contracts effectively makes them end up working like transaction fees in any case. Considering the near-failure in just keeping development funded, I'm not sure where the believe this this model will be workable comes from; in particular unlike a lighthouse (but like development) security is ongoing and not primarily a fixed one time cost. I note that many existing crowdfunding platforms (including your own) do not do ongoing costs with this kind of binary contract. Also work reminding people that mining per-contract is a long identified existential risk to Bitcoin which has been seeing more analysis lately: http://www.jbonneau.com/doc/BFGKN14-bitcoin_bribery.pdf -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
I wrote an article that explains the hashing assurance contract concept: https://medium.com/@octskyward/hashing-7d04a887acc8 (it doesn't contain an in depth protocol description) -- ___ 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%
Hi Peter, Thanks for your reply. I know and bookmarked your branch - nice work. So, to clarify: - bitcoin core (official / default) 0.10.x currently has First-seen mempool behavior - your custom branch uses replace by fee mempool behavior which allows an user to change anything in a tx (I guess it needs just to have at least one same input, so it can link it to another previously signed tx with lower fee and substitute it in the mempool, correct?). - First Seen Safe Replace by Fee (FSF-RBF) mempool behavior which allows an user only to add inputs and/or increase the value of outputs will be in yet another branch, maintained by you, but not in default / official bitcoin core? Another thing, if FSF-RBF lets you change TXes in the manner described above, how does the client know which tx needs to be replaced in the mempool? Since the txid naturally changes. How does it map tx1 with tx2 (to know tx2 has a higher fee and needs to substitute tx1) if quite a lot of params from the transaction structure can change? Thanks! On 5/27/2015 4:25 AM, Peter Todd wrote: > On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote: >> What is wrong with the man testing some ideas on his custom branch? This >> is how improvements come to life. I saw in the BIPs some really >> interesting ideas and nice brainstorming which came from Peter Todd. >> >> Now, my question, if replace by fee doesn't allow me to change the >> inputs or the outputs, I can only add outputs... what can I do with this >> feature? If I sent a tx and want to replace it with a higher fee one, >> the higher fee one can only have maybe additional change addresses or >> another payment, if the inputs suffice? Do we have any real use cases? > > You're a bit mistaken there: standard RBF lets you change anything, and > FSS RBF lets you modify inputs and add outputs and/or make the value of > outputs higher. > >> P.S. is it planned to include this by default in bitcoin core 10.0.3 or >> it will remain just on Peter's branch? > > Any significant change to mempool policy like RBF is very unlikely to be > incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be > too large a change for a minor, mostly bugfix, release. > > Having said that, I already maintain a standard RBF branch for v0.10.x, > and have been asked by a major minor to backport FSS RBF for v0.10.x as > well. > -- ___ 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
> > Mike, this proposal was purposefully constructed to maintain as well as > possible the semantics of Satoshi's original construction. Higher sequence > numbers -- chronologically later transactions -- are able to hit the chain > earlier, and therefore it can be reasonably argued will be selected by > miners before the later transactions mature. Did I fail in some way to > capture that original intent? > Right, but the original protocol allowed for e.g. millions of revisions of the transaction, hence for high frequency trading (that's actually how Satoshi originally explained it to me - as a way to do HFT - back then the channel concept didn't exist). As you point out, with a careful construction of channels you should only need to bump the sequence number when the channel reverses direction. If your app only needs to do that rarely, it's a fine approach.And your proposal does sounds better than sequence numbers being useless like at the moment. I'm just wondering if we can get back to the original somehow or at least leave a path open to it, as it seems to be a superset of all other proposals, features-wise. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
On May 27, 2015 12:58 PM, "Peter Todd" wrote: > What I'm not seeing is how the relative nLockTime that nSequence > provides fundamentally changes any of this. This allows the implementation of a rcltv that doesn't make script depend on the current height, in a similar way that cltv uses the nLockTime (which has been compared with the current height already when checking the script). In fact, the implementation could be simpler if the goal of maintaining the original nSequence semantics was ignored ( although not that simpler, but you wouldn't need to use ~ (bitwise not). I'm still not sure whether there should be 2 BIPs for this or just one. > -- > 'peter'[:-1]@petertodd.org > 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn wrote: > > As I believe out of all proposed protocols Satoshi's is still the most > powerful, I would suggest that any change to the semantics on nSequence be > gated by a high bit or something, so the original meaning remains available > if/when resource scheduling and update flood damping are implemented. That > way people can try it out and if miners are breaking things too frequently > by ignoring the chronological ordering people can abandon protocols that > rely on it, and if they aren't they can proceed and benefit from the > greater flexibility. > > Mike, this proposal was purposefully constructed to maintain as well as possible the semantics of Satoshi's original construction. Higher sequence numbers -- chronologically later transactions -- are able to hit the chain earlier, and therefore it can be reasonably argued will be selected by miners before the later transactions mature. Did I fail in some way to capture that original intent? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
On Wed, May 27, 2015 at 11:15 AM, Peter Todd wrote:
> The median time mechanism is basically a way for hashing power to show
> what time they think it is. Equally, the nVersion soft-fork mechanism is
> a way for hashing power to show what features they want to support.
>
>
Fair enough. It means slightly more processing, but the median time could
be cached in the header index, so no big deal.
Block counts are inconvenient for planning, as there's no guarantee
> they'll actually happen in any particular time frame, forward and back.
>
I don't think the deadline needs to be set that accurately. A roughly 6
month deadline should be fine, but as you say a majority of miners is
needed to abuse the median time and it is already a miner poll.
Perhaps the number of blocks used in the median could be increased to
reduce "noise".
The median time could be median of the last 144 blocks plus 12 hours.
> If you assume no large reorganizations, your table of known BIPs can
> just as easily be a list of block heights even if the median time
> mechanism is used.
>
I think it makes it easier to write the code. It reduced the state that
needs to be stored per BIP. You don't need to check if the previous bips
were all accepted.
Each bit is assigned to a particular BIP for a particular range of times
(or blocks).
If block numbers were used for the deadline, you just need to check the
block index for the deadline block.
enum {
BIP_INACTIVE = 0,
BIP_ACTIVE,
BIP_LOCKED
BIP_INVALID_BLOCK,
}
int GetBIPState(block, bip)
{
if (block.height == bip.deadline) // Bit must be set to match
locked/unlocked at deadline
{
int bipState = check_supermajority(...);
if (bipState == BIP_LOCKED && (block.nVersion & bip.bit)
return BIP_LOCKED;
if (bipState != BIP_LOCKED && (block.nVersion & (~bip.bit)))
return BIP_INACTIVE;
return BIP_INVALID_BLOCK;
}
if (block.height > deadline) // Look at the deadline block to determine
if the BIP is locked
return (block_index[deadline].nVersion & bip_bit) != 0 ? BIP_LOCKED
: BIP_INACTIVE;
if (block.height < startline + I) // BIP cannot activate/lock until
startline + implicit window size
return INACTIVE;
return check_supermajority() // Check supermajority of bit
}
The block at height deadline would indicate if the BIP was locked in.
Block time could still be used as long as the block height was set after
that. The deadline_time could be in six months. The startline height
could be the current block height and the deadline_height could be
startline + 35000.
The gives roughly
start time = now
deadline time = now + six months
deadline height = now + eight months
The deadline height is the block height when the bit is returned to the
pool but the deadline time is when the BIP has to be accepted.
It also helps with the warning system. For each block height, there is a
set of known BIP bits that are allowed. Once the final deadline is passed,
the expected mask is zeros.
On Wed, May 27, 2015 at 11:15 AM, Jorge Timón wrote:
> On May 27, 2015 11:35 AM, "Tier Nolan" wrote:
>
> > Was the intention to change the 95% rule. You need 750 of the last 1000
> to activate and then must wait at least 1000 for implication?
>
> You need 75% to start applying it, 95% to start rejecting blocks that
> don't apply it.
>
I think the phrasing is ambiguous. I was just asking for clarification.
"Whenever I out of any W *subsequent* blocks (regardless of the block
itself) have bit B set,"
That suggests that the I of W blocks for the 95% rule must happen after
activation. This makes the rule checking harder. Easier to use the
current system, where blocks that were part of the 750 rule also count
towards the 95% rule.
--
___
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
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote: > On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > > Equally this proposal is no more "consensus enforcement" than simply > > increasing the fee (and possibly decreasing the absolute nLockTime) for > > You've misunderstood it, I think-- Functionally nlocktime but relative > to each txin's height. > > But the construction gives the sequence numbers a rational meaning, > they count down the earliest position a transaction can be included. > (e.g. the highest possible sequence number can be included any time > the inputs are included) the next lower sequence number can only be > included one block later than the input its assigned to is included, > the next lower one block beyond that. All consensus enforced. A > miner could opt to not include the higher sequence number (which is > the only one of the set which it _can_ include) it the hopes of > collecting more fees later on the next block, similar to how someone > could ignore an eligible locked transaction in the hopes that a future > double spend will be more profitable (and that it'll enjoy that > profit) but in both cases it must take nothing at all this block, and > risk being cut off by someone else (and, of course, nothing requires > users use sequence numbers only one apart...). I understand that part. I'm just saying it's not clear to me what's the functional difference in practice between it and having both parties sign a decreasing absolute nLockTime. For instance, you and I could setup a payment channel using the following transaction t0: 1.0 BTC: PT -> 1.0 BTC: PT && (GM || CLTV) 1.0 BTC: GM -> 1.0 BTC: GM && (PT || CLTV) After both of us are guaranteed to get our funds back regardless. I can then give you funds by signing my part of t1a: t0.vout[0] -> 0.5 BTC: PT t0.vout[1] -> 1.5 BTC: GM nLockTime = You can then give me funds with t1b: t0.vout[0] -> 1.5 BTC: PT t0.vout[1] -> 0.5 BTC: GM nLockTime = etc. etc. We can close the channel by signing a non-nLockTime'd tx at any time. If you don't co-operate, I have to wait, and hope I get my tx mined before you get yours. What I'm not seeing is how the relative nLockTime that nSequence provides fundamentally changes any of this. -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
Also think it would be useful.
Created an issue for it some time back:
https://github.com/bitcoin/bitcoin/issues/3802
I think nodes don't "only" have to connect to LAN nodes. Especially with
headers first.
They can still connect to other nodes as well. Having said that security
is problematic in any case on a hotel wifi or similar. All traffic can be
spoofed.
With HF they'd be loading most of the data from the LAN node though.
This will help people having multiple nodes at home reduce bandwidth and
improve sync without difficult setup.
On Tue, 26 May 2015 at 12:50 Mike Hearn wrote:
> Very interesting Matt.
>
> For what it's worth, in future bitcoinj is very likely to bootstrap from
> Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily
> working towards Tor by default. So this approach will probably stop working
> at some point. As breaking PorcFest would kind of suck, we might want a
> ZeroConf/Rendezvous solution in place so local LANs can capture Bitcoin
> traffic away from Tor (with some notification to the user, presumably).
>
>
>
> On Tue, May 26, 2015 at 7:47 AM, Matt Whitlock
> wrote:
>
>> On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
>> > On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
>> > > On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
>> > > > Do any wallets actually do this yet?
>> > >
>> > > Not that I know of, but they do seed their address database via DNS,
>> which you can poison if you control the LAN's DNS resolver. I did this for
>> a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well
>> over a hundred lightweight wallets, all trying to connect to the Bitcoin
>> P2P network over a very bandwidth-constrained Internet link, so I poisoned
>> the DNS and rejected all outbound connection attempts on port 8333, to
>> force all the wallets to connect to a single local full node, which had
>> connectivity to a single remote node over the Internet. Thus, all the
>> lightweight wallets at the festival had Bitcoin network connectivity, but
>> we only needed to backhaul the Bitcoin network's transaction traffic once.
>> >
>> > Interesting!
>> >
>> > What festival was this?
>>
>> The Porcupine Freedom Festival ("PorcFest") in New Hampshire last summer.
>> I strongly suspect that it's the largest gathering of Bitcoin users at any
>> event that is not specifically Bitcoin-themed. There's a lot of overlap
>> between the Bitcoin and liberty communities. PorcFest draws somewhere
>> around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on
>> their mobile devices.
>>
>> The backhaul was a 3G cellular Internet connection, and the local Bitcoin
>> node and network router were hosted on a Raspberry Pi with some Netfilter
>> tricks to restrict connectivity. The net result was that all Bitcoin nodes
>> (lightweight and heavyweight) on the local Wi-Fi network were unable to
>> connect to any Bitcoin nodes except for the local node, which they
>> discovered via DNS. I also had provisions in place to allow outbound
>> connectivity to the API servers for Mycelium, Blockchain, and Coinbase
>> wallets, by feeding the DNS resolver's results in real-time into a
>> whitelisting Netfilter rule utilizing IP Sets.
>>
>> For your amusement, here's the graphic for the banner that I had made to
>> advertise the network at the festival (*chuckle*):
>> http://www.mattwhitlock.com/bitcoin_wifi.png
>>
>>
>> --
>> 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
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
On May 27, 2015 11:35 AM, "Tier Nolan" wrote: > Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? You need 75% to start applying it, 95% to start rejecting blocks that don't apply it. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote: > I think it would be better to have the deadlines set as block counts. That > eliminates the need to use the median time mechanism. The median time mechanism is basically a way for hashing power to show what time they think it is. Equally, the nVersion soft-fork mechanism is a way for hashing power to show what features they want to support. Block counts are inconvenient for planning, as there's no guarantee they'll actually happen in any particular time frame, forward and back. There's no particular incentive problems here - the median time clearly shows support by a majority of hashing power - so I don't see any reason to make planning more difficult. > The deadline could be matched to a "start-line". The definition would then > be something like > > BIP 105 > Start block: 325000 > End block: 35 > Activation: 750 of 1000 > Implication: 950 of 1000 > Bit: 9 > > This would allow creation of a simple table of known BIPs. It also keeps > multiple users of the bit as strictly separate. If you assume no large reorganizations, your table of known BIPs can just as easily be a list of block heights even if the median time mechanism is used. If you do assume there may be large reorganizations you can't have a "simple table" -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 signature.asc Description: Digital signature -- ___ 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
> > 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. > Yes indeed they were. Satoshis mechanism was more general than micropayment channels and could do HFT between any set of parties. > 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. > Safe is relative - this is the same logic the original replace-by-fee argument uses. There's no enforcement that miners use any particular ordering of transactions. 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. -- ___ 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
This could cause legacy transactions to become unspendable. A new transaction version number should be used to indicate the change of the field from sequence number to relative lock time. Legacy transactions should not have the rule applied to them. On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell wrote: > On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > > Equally this proposal is no more "consensus enforcement" than simply > > increasing the fee (and possibly decreasing the absolute nLockTime) for > > You've misunderstood it, I think-- Functionally nlocktime but relative > to each txin's height. > > But the construction gives the sequence numbers a rational meaning, > they count down the earliest position a transaction can be included. > (e.g. the highest possible sequence number can be included any time > the inputs are included) the next lower sequence number can only be > included one block later than the input its assigned to is included, > the next lower one block beyond that. All consensus enforced. A > miner could opt to not include the higher sequence number (which is > the only one of the set which it _can_ include) it the hopes of > collecting more fees later on the next block, similar to how someone > could ignore an eligible locked transaction in the hopes that a future > double spend will be more profitable (and that it'll enjoy that > profit) but in both cases it must take nothing at all this block, and > risk being cut off by someone else (and, of course, nothing requires > users use sequence numbers only one apart...). > > It makes sequence numbers work exactly like you'd expect-- within the > bounds of whats possible in a decentralized system. At the same time, > all it is ... is relative nlocktime. > > > -- > ___ > 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] Version bits proposal
I think it would be better to have the deadlines set as block counts. That eliminates the need to use the median time mechanism. The deadline could be matched to a "start-line". The definition would then be something like BIP 105 Start block: 325000 End block: 35 Activation: 750 of 1000 Implication: 950 of 1000 Bit: 9 This would allow creation of a simple table of known BIPs. It also keeps multiple users of the bit as strictly separate. The alternative to the start time is that it is set equal to the deadline or implication time of the previous user of the bit. Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? On Wed, May 27, 2015 at 4:51 AM, Jorge Timón wrote: > It would also help to see the actual code changes required, which I'm sure > will be much shorter than the explanation itself. > On May 27, 2015 5:47 AM, "Luke Dashjr" wrote: > >> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote: >> > Feel free to comment. As the gist does not support notifying >> participants >> > of new comments, I would suggest using the mailing list instead. >> >> I suggest adding a section describing how this interacts with and changes >> GBT. >> >> Currently, the client tells the server what the highest block version it >> supports is, and the server indicates a block version to use in its >> template, >> as well as optional instructions for the client to forcefully use this >> version >> despite its own maximum version number. Making the version a bitfield >> contradicts the increment-only assumption of this design, and since GBT >> clients are not aware of overall network consensus state, reused bits can >> easily become confused. I suggest, therefore, that GBT clients should >> indicate >> (instead of a maximum supported version number) a list of softforks by >> identifier keyword, and the GBT server respond with a template indicating: >> - An object of softfork keywords to bit values, that the server will >> accept. >> - The version number, as presently conveyed, indicating the preferred >> softfork >> flags. >> >> Does this sound reasonable, and/or am I missing anything else? >> >> Luke >> >> >> -- >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote: > Equally this proposal is no more "consensus enforcement" than simply > increasing the fee (and possibly decreasing the absolute nLockTime) for You've misunderstood it, I think-- Functionally nlocktime but relative to each txin's height. But the construction gives the sequence numbers a rational meaning, they count down the earliest position a transaction can be included. (e.g. the highest possible sequence number can be included any time the inputs are included) the next lower sequence number can only be included one block later than the input its assigned to is included, the next lower one block beyond that. All consensus enforced. A miner could opt to not include the higher sequence number (which is the only one of the set which it _can_ include) it the hopes of collecting more fees later on the next block, similar to how someone could ignore an eligible locked transaction in the hopes that a future double spend will be more profitable (and that it'll enjoy that profit) but in both cases it must take nothing at all this block, and risk being cut off by someone else (and, of course, nothing requires users use sequence numbers only one apart...). It makes sequence numbers work exactly like you'd expect-- within the bounds of whats possible in a decentralized system. At the same time, all it is ... is relative nlocktime. -- ___ 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
Please remove me from the mailing list 2015-05-27 3:50 GMT+02:00 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 > > -- ___ 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
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote: > 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. Can you provide a worked example of this in use? I think I see a major flaw, but I'd like to see a worked example first. Keep in mind that there's absolutely no reason to have pending transactions in mempools until we actually expect them to be mined. Equally this proposal is no more "consensus enforcement" than simply increasing the fee (and possibly decreasing the absolute nLockTime) for each replacement would be; increasing the fee for each mempool replacement is a hard requirement as an anti-DoS anyway. (this was all discussed on the mailing list two years ago when RBF was first proposed) -- 'peter'[:-1]@petertodd.org 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 signature.asc Description: Digital signature -- ___ 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
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote: > 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. To clarify a point raised(1) on the pull-req itself: The replacement transaction is allowed to not only add new txin's, but also replace txins. Suppose t1 is a 2-in-2-out P2PKH using transaction, 374 bytes in size. With CPFP accomplished by a 1-in-1-out tx, 192 bytes, you have 566 bytes total. With FSS RBF if you have an unspent output greater in value than one of the outputs spent by t1, you can replace that output in t1's vin txin set and rebroadcast the transaction, still 374 bytes in size. This gives you a 34% cost savings vs. CPFP. > 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% Similarly in the multiple recipients case, if sufficiently large outputs are available the additional funds can be obtained by swapping one input for another. For instance if Alice has three outputs, 1.0, 0.5, and 0.2 BTC, and needs to pay Bob 1.1 BTC, she can create t1: 1.0 -> Bob 1.1 0.2 -> Alice 0.1 If she then needs to pay Charlie 0.2 BTC she can doublespend that with: 1.0 -> Bob 1.1 0.5 -> Charlie 0.2 -> Alice 0.2 Note that care does need to be taken to ensure that multiple rounds of this always leave at least one input unchanged. 1) https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-105630255 -- 'peter'[:-1]@petertodd.org 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
