Danny Thorpe [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-12 to 2017-10-30
💬 Posted a total of 22 messages
📚 Participated in the following categories: Bitcoin-development, RFC, bitcoin-dev, BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87

Profile Code

nprofile1qqsq2gyvwmynthgjwjc4kfssv7uxyc4qa0h08mmv6g3mff5jlmhzhrcpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgcwaehxw309aex2mrp0yhxummnwa5x2un99e3k7mg5tl8z7

Publishing to

relay.nostr.band

relay.noswhere.com

Author Public Key

npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87

Show more details

Last Notes

2023-06-07 18:07:15

- reply

📅 Original date posted:2017-10-30
📝 Original message:Humans are very visually oriented, recognizing differences in images more
easily than differences in text.
What about generating an image based on the bytes of an address, using
something like identicon, used by gravatar? Any small change to the text
input produces a significantly different image.
-Danny
On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If you are going to rely on human verification of addresses, the best way
> might be map it to words.
>
> For example, with a 6000 word list, a 25 byte address (with a checksum)
> could be mapped to 16 words like this:
>
> vocally acquire removed unfounded
> euphemism sanctuary sectional driving
> entree freckles aloof vertebrae
> scribble surround prelaw effort
>
> In my opinion, that is much faster to verify than this:
>
> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>
> or
>
> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>
> Although I really do love Bech32.
>
> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>> 62 bytes ! This is very very long. This will create lot of usability
>> problems in
>>
>> - Blockexplorers (atleast user should be visually able to compare in a
>> transaction having multiple outputs which one his address)
>> - Mobiles
>> - Payment terminals
>>
>> From my limited understanding, the purpose of inventing a bitcoin address
>> format is for usability and ease of identification (versus a ECDSA public
>> key), While I get the error/checksum capabilities Bech32 brings, any user
>> would prefer a 20 byte address with a checksum over an address that would
>> wrap several lines !!
>>
>>
>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>> thompson.benedictjames at gmail.com> wrote:
>>
>>> Checking the first few bytes of a Bitcoin Address should not be
>>> considered sufficient for ensuring that it is correct as it takes less than
>>> a second to generate a 3 character vanity address that matches the first 3
>>> characters of an address.
>>>
>>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> When I copy and paste bitcoin address, I double check the first few
>>>> bytes, to make sure I copied the correct one. This is to make sure some
>>>> rogue software is not changing the address, or I incorrectly pasted the
>>>> wrong address.
>>>>
>>>>
>>>> With Bech32 address, its seems like in this department we are taking as
>>>> step in the backward direction. With the traditional address, I could
>>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>>> and compare which is likely to be same anyway. Note that most users will
>>>> only compare the first few bytes only (since addresses themselves are very
>>>> long and will overflow in a mobile text box).
>>>>
>>>> Is there anyway to make the Bech32 addresses format more visually
>>>> distinct (atleast the first few bytes) ?
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171030/ec4752a9/attachment.html>

2023-06-07 18:00:17

- reply

📅 Original date posted:2017-04-17
📝 Original message:1TB HDD is now available for under $40 USD. How is the 100GB storage
requirement preventing anyone from setting up full nodes?
On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> *Rationale:*
>
> A node that stores the full blockchain (I will use the term archival node)
> requires over 100GB of disk space, which I believe is one of the most
> significant barriers to more people running full nodes. And I believe the
> ecosystem would benefit substantially if more users were running full nodes.
>
> The best alternative today to storing the full blockchain is to run a
> pruned node, which keeps only the UTXO set and throws away already verified
> blocks. The operator of the pruned node is able to enjoy the full security
> benefits of a full node, but is essentially leeching the network, as they
> performed a large download likely without contributing anything back.
>
> This puts more pressure on the archival nodes, as the archival nodes need
> to pick up the slack and help new nodes bootstrap to the network. As the
> pressure on archival nodes grows, fewer people will be able to actually run
> archival nodes, and the situation will degrade. The situation would likely
> become problematic quickly if bitcoin-core were to ship with the defaults
> set to a pruned node.
>
> Even further, the people most likely to care about saving 100GB of disk
> space are also the people least likely to care about some extra bandwidth
> usage. For datacenter nodes, and for nodes doing lots of bandwidth, the
> bandwidth is usually the biggest cost of running the node. For home users
> however, as long as they stay under their bandwidth cap, the bandwidth is
> actually free. Ideally, new nodes would be able to bootstrap from nodes
> that do not have to pay for their bandwidth, instead of needing to rely on
> a decreasing percentage of heavy-duty archival nodes.
>
> I have (perhaps incorrectly) identified disk space consumption as the most
> significant factor in your average user choosing to run a pruned node or a
> lite client instead of a full node. The average user is not typically too
> worried about bandwidth, and is also not typically too worried about
> initial blockchain download time. But the 100GB hit to your disk space can
> be a huge psychological factor, especially if your hard drive only has
> 500GB available in the first place, and 250+ GB is already consumed by
> other files you have.
>
> I believe that improving the disk usage situation would greatly benefit
> decentralization, especially if it could be done without putting pressure
> on archival nodes.
>
> *Small Nodes Proposal:*
>
> I propose an alternative to the pruned node that does not put undue
> pressure on archival nodes, and would be acceptable and non-risky to ship
> as a default in bitcoin-core. For lack of a better name, I'll call this new
> type of node a 'small node'. The intention is that bitcoin-core would
> eventually ship 'small nodes' by default, such that the expected amount of
> disk consumption drops from today's 100+ GB to less than 30 GB.
>
> My alternative proposal has the following properties:
>
> + Full nodes only need to store ~20% of the blockchain
> + With very high probability, a new node will be able to recover the
> entire blockchain by connecting to 6 random small node peers.
> + An attacker that can eliminate a chosen+ 95% of the full nodes running
> today will be unable to prevent new nodes from downloading the full
> blockchain, even if the attacker is also able to eliminate all archival
> nodes. (assuming all nodes today were small nodes instead of archival nodes)
>
> Method:
>
> A small node will pick an index [5, 256). This index is that node's
> permanent index. When storing a block, instead of storing the full block,
> the node will use Reed-Solomon coding to erasure code the block using a
> 5-of-256 scheme. The result will be 256 pieces that are 20% of the size of
> the block each. The node picks the piece that corresponds to its index, and
> stores that instead. (Indexes 0-4 are reserved for archival nodes -
> explained later)
>
> The node is now storing a fragment of every block. Alone, this fragment
> cannot be used to recover any piece of the blockchain. However, when paired
> with any 5 unique fragments (fragments of the same index will not be
> unique), the full block can be recovered.
>
> Nodes can optionally store more than 1 fragment each. At 5 fragments, the
> node becomes a full archival node, and the chosen indexes should be 0-4.
> This is advantageous for the archival node as the encoded data for the
> first 5 indexes will actually be identical to the block itself - there is
> no computational overhead for selecting the first indexes. There is also no
> need to choose random indexes, because the full block can be recovered no
> matter which indexes are chosen.
>
> When connecting to new peers, the indexes of each peer needs to be known.
> Once peers totaling 5 unique indexes are discovered, blockchain download
> can begin. Connecting to just 5 small node peers provides a >95% chance of
> getting 5 uniques, with exponentially improving odds of success as you
> connect to more peers. Connecting to a single archive node guarantees that
> any gaps can be filled.
>
> A good encoder should be able to turn a block into a 5-of-256 piece set in
> under 10 milliseconds using a single core on a standard consumer desktop.
> This should not slow down initial blockchain download substantially, though
> the overhead is more than a rounding error.
>
> *DoS Prevention:*
>
> A malicious node may provide garbage data instead of the actual piece.
> Given just the garbage data and 4 other correct pieces, it is impossible
> (best I know anyway) to tell which piece is the garbage piece.
>
> One option in this case would be to seek out an archival node that could
> verify the correctness of the pieces, and identify the malicious node.
>
> Another option would be to have the small nodes store a cryptographic
> checksum of each piece. Obtaining the cryptographic checksum for all 256
> pieces would incur a nontrivial amount of hashing (post segwit, as much as
> 100MB of extra hashing per block), and would require an additional ~4kb of
> storage per block. The hashing overhead here may be prohibitive.
>
> Another solution would be to find additional pieces and brute-force
> combinations of 5 until a working combination was discovered. Though this
> sounds nasty, it should take less than five seconds of computation to find
> the working combination given 5 correct pieces and 2 incorrect pieces. This
> computation only needs to be performed once to identify the malicious peers.
>
> I also believe that alternative erasure coding schemes exist which
> actually are able to identify the bad pieces given sufficient good pieces,
> however I don't know if they have the same computational performance as the
> best Reed-Solomon coding implementations.
>
> *Deployment:*
>
> Small nodes are completely useless unless the critical mass of 5 pieces
> can be obtained. The first version that supports small node block downloads
> should default everyone to an archival node (meaning indexes 0-4 are used)
>
> Once there are enough small-node-enabled archive nodes, the default can be
> switched so that nodes only have a single index by default. In the first
> few days, when there are only a few small nodes, the previously-deployed
> archival nodes can help fill in the gaps, and the small nodes can be useful
> for blockchain download right away.
>
> ----------------------------------
>
> This represents a non-trivial amount of code, but I believe that the
> result would be a non-trivial increase in the percentage of users running
> full nodes, and a healthier overall network.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/02c3dd58/attachment-0001.html>

2023-06-07 17:49:05

- reply

📅 Original date posted:2016-02-12
📝 Original message:"With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
resources."
That doesn't match my experience.
System responsiveness / user experience can suffer when running bitcoin-qt
on a spinning hard disk. Disk I/O load will cause the whole system to grind
and severely disrupt the user experience.
Move the Bitcoin data to an SSD, though, and it's an entirely different
story.
The initial blockchain synchronization / "catch up" is CPU and disk
intensive, but after initial sync I find bitcoin-qt uses only a trivial
amount of CPU to keep up with verifying new blocks and new transactions.
Running bitcoin-qt occasionally is a much more painful user experience than
running bitcoin-qt continuously.
I'm running Bitcoin Core v0.12.rc2 on an old dual core Pentium E2160 at
1.8GHz, 6GB RAM, 64 bit Windows 10, with the Bitcoin data on SSD. This
system is about 6 years old and was an economy model even when new. Not
what I would call a powerful system. I've only added RAM and the SSD.
On that machine I run two instances of Bitcoin-qt - one for mainnet, and
another for testnet, and an instance of bfgminer to manage a handful of USB
Block Eruptors for testnet mining. Both bitcoin-qt instances are typically
at their max of 25 connections (each). Total CPU load floats around 11%,
with only occasional spikes to 40% for a few seconds. The mainnet
bitcoin-qt process uses about 700MB of RAM, testnet about 300MB.
This machine did fall into disk grinding paralysis during initial sync /
catchup with the v0.10 and v0.11 builds of bitcoin-qt, when the Bitcoin
data was on a spinning disk. Moving the Bitcoin data to an SSD drive had
the greatest impact on breaking the disk-bound whole-system paralysis.
Increasing the system RAM, upgrading to v0.12, and upgrading the OS to Win
10 all contributed smaller improvements.
It is possible to run a full node on a small desktop machine concurrent
with user apps. Just get the Bitcoin data off of spinning media and onto
SSD, make sure you have plenty of RAM, and leave bitcoin-qt running all the
time.
-Danny
On Wed, Feb 10, 2016 at 11:03 PM, Patrick Shirkey via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote:
> > I've been asked to post this to this mailing list too. It's time to
> > clear up some misconceptions floating around about full nodes.
> >
> > === Myth: There are only about 5500 full nodes worldwide ===
> >
> > This number comes from this and similar sites: https://bitnodes.21.co/
> > and it measured by trying to probe every nodes on their open ports.
> >
> > Problem is, not all nodes actually have open ports that can be probed.
> > Either because they are behind firewalls or because their users have
> > configured them to not listen for connections.
> >
> > Nobody knows how many full nodes there are, since many people don't know
> > how to forward ports behind a firewall, and bandwidth can be costly, its
> > quite likely that the number of nodes with closed ports is at least
> > another several thousand.
> >
> > Nodes with open ports are able to upload blocks to new full nodes. In
> > all other ways they are the same as nodes with closed ports. But because
> > open-port-nodes can be measured and closed-port-nodes cannot, some
> > members of the bitcoin community have been mistaken into believing that
> > open-port-nodes are that matters.
> >
> > === Myth: This number of nodes matters and/or is too low. ===
> >
> > Nodes with open ports are useful to the bitcoin network because they
> > help bootstrap new nodes by uploading historical blocks, they are a
> > measure of bandwidth capacity. Right now there is no shortage of
> > bandwidth capacity, and if there was it could be easily added by renting
> > cloud servers.
> >
> > The problem is not bandwidth or connections, but trust, security and
> > privacy. Let me explain.
> >
> > Full nodes are able to check that all of bitcoin's rules are being
> > followed. Rules like following the inflation schedule, no double
> > spending, no spending of coins that don't belong to the holder of the
> > private key and all the other rules required to make bitcoin work (e.g.
> > difficulty)
> >
> > Full nodes are what make bitcoin trustless. No longer do you have to
> > trust a financial institution like a bank or paypal, you can simply run
> > software on your own computer. To put simply, the only node that matters
> > is the one you use.
> >
> > === Myth: There is no incentive to run nodes, the network relies on
> > altruism ===
> >
> > It is very much in the individual bitcoin's users rational self interest
> > to run a full node and use it as their wallet.
> >
> > Using a full node as your wallet is the only way to know for sure that
> > none of bitcoin's rules have been broken. Rules like no coins were spent
> > not belonging to the owner, that no coins were spent twice, that no
> > inflation happens outside of the schedule and that all the rules needed
> > to make the system work are followed (e.g. difficulty.) All other kinds
> > of wallet involve trusting a third party server.
> >
> > All these checks done by full nodes also increase the security. There
> > are many attacks possible against lightweight wallets that do not affect
> > full node wallets.
> >
> > This is not just mindless paranoia, there have been real world examples
> > where full node users were unaffected by turmoil in the rest of the
> > bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many
> > kinds of wallets. Here is the wiki page on this event
> > https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice
> >
> > Notice how updated node software was completely unaffected by the fork.
> > All other wallets required either extra confirmations or checking that
> > the third-party institution was running the correct version.
> >
> > Full nodes wallets are also currently the most private way to use
> > Bitcoin, with nobody else learning which bitcoin addresses belong to
> > you. All other lightweight wallets leak information about which
> > addresses are yours because they must query third-party servers. The
> > Electrum servers will know which addresses belong to you and can link
> > them together. Despite bloom filtering, lightweight wallets based on
> > BitcoinJ do not provide much privacy against nodes who connected
> > directly to the wallet or wiretappers.
> >
> > For many use cases, such privacy may not be required. But an important
> > reason to run a full node and use it as a wallet is to get the full
> > privacy benefits.
> >
> > === Myth: I can just set up a node on a cloud server instance and leave
> > it ===
> >
> > To get the benefits of running a full node, you must use it as your
> > wallet, preferably on hardware you control.
> >
> > Most people who do this do not use a full node as their wallet.
> > Unfortunately because Bitcoin has a similar name to Bittorrent, some
> > people believe that upload capacity is the most important thing for a
> > healthy network. As I've explained above: bandwidth and connections are
> > not a problem today, trust, security and privacy are.
> >
> > === Myth: Running a full node is not recommended, most people should use
> > a lightweight client ===
> >
> > This was common advice in 2012, but since then the full node software
> > has vastly improved in terms of user experience.
> >
> > If you cannot spare the disk space to store the blockchain, you can
> > enable pruning as in:
> > https://bitcoin.org/en/release/v0.11.0#block-file-pruning. In Bitcoin
> > Core 0.12, pruning being enabled will leave the wallet enabled.
> > Altogether this should require less than 1.5GB of hard disk space.
> >
> > If you cannot spare the bandwidth to upload blocks to other nodes, there
> > are number of options to reduce or eliminate the bandwidth requirement
> > found in https://bitcoin.org/en/full-node#reduce-traffic . These include
> > limiting connections, bandwidth targetting and disabling listening.
> > Bitcoin Core 0.12 has the new option -blocksonly, where the node will
> > not download unconfirmed transaction and only download new blocks. This
> > more than halves the bandwidth usage at the expense of not seeing
> > unconfirmed transactions.
> >
> > Synchronizing the blockchain for a new node has improved since 2012 too.
> > Features like headers-first
> > (https://bitcoin.org/en/release/v0.10.0#faster-synchronization) and
> > libsecp256k1 have greatly improved the initial synchronization time.
> >
> > It can be further improved by setting -dbcache=6000 which keeps more of
> > the UTXO set in memory. It reduces the amount of time reading from disk
> > and therefore speeds up synchronization. Tests showed that the entire
> > blockchain can now be synchronized in less than _3 and a half hours_
> > (See
> > https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958)
> > Note that you'll need Bitcoin Core 0.12 or later to get all these
> > efficiency improvements.
> >
> > === How to run a full node as your wallet ===
> >
> > I think every moderate user of bitcoin would benefit by running a full
> > node and using it as their wallet. There are several ways to do this.
> >
> > * Run a bitcoin-qt full node (https://bitcoin.org/en/download).
> >
> > * Use wallet software that is backed by a full node e.g. Armory
> > (https://bitcoinarmory.com/) or JoinMarket
> > (https://github.com/AdamISZ/JMBinary/#jmbinary)
> >
> > * Use a lightweight wallet that connects only to your full node (e.g.
> > Multibit connecting only to your node running at home, Electrum
> > connecting only to your own Electrum server)
> >
> > So what are you waiting for? The benefits are many, the downsides are
> > not that bad. The more people do this, the more robust and healthy the
> > bitcoin ecosystem is.
> >
> >
>
> This is very useful information but from my experience it is not viable to
> have a full node running full time on a desktop system i.e sharing the
> system with a normal desktop workload.
>
> With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
> resources. Surely the majority of nodes NOT running open ports are being
> run on desktop systems. It's likely that the vast majority of the
> "normal/desktop" user base are not going to setup dedicated machines to
> run a full node full time.
>
> It's likely that the vast majority of full nodes that are not running open
> ports are used occasionally when the user wants to make a transaction or
> "catch up" with the blockchain.
>
> That creates a divide between those who do have the resources to
> contribute to the system on a full time basis (minority) and those who do
> not (majority).
>
> Does the power of p2p decentralization lie with the vast majority or the
> "wealthy" resource rich minority?
>
> How will the move to 2MB hard fork affect the vast majority of nodes?
>
> For example Debian unstable currently provides the following:
>
> apt-cache madison bitcoin-qt
> bitcoin-qt | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main amd64
> Packages
> bitcoin | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main Sources
>
>
> The rollout affect of the hard fork on the entire bitcoin ecosystem is a
> difficult process to plan in advance. It's not viable to simply rely on
> press releases to encourage users to upgrade their nodes. The debacle with
> Pulse Audio during the mid 2000's should be a lesson for those who seek
> that route.
>
> Compare that to the requirements for spinning up "bitcoin-2.0" and
> enabling users to move their wallets to the new blockchain at their
> leisure.
>
> The ecosystem doesn't suffer from instant degradation. Bitcoin "brand"
> loyalty will ensure that users who want to move forward with the economic
> potential of the 2MB blocksize will be able to keep their existing funds
> safe while testing the waters with the new blocksize.
>
> After all Bitcoin is still the only game in town when it comes to scale
> and proven history of financial return.
>
> As the new blockchain builds momentum the old one will eventually become
> obsolete. However it may also become the digital equivalency of Silver and
> that is also a useful, profitable and viable alternative with a proven
> history of success.
>
>
>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/44d91731/attachment-0001.html>

2023-06-07 17:46:17

- reply

📅 Original date posted:2015-12-13
📝 Original message:What is the current behavior / cost that this proposal is trying to avoid?
Are ancient utxos required to be kept in memory always in a fully
validating node, or can ancient utxos get pushed out of memory like a
normal LRU caching db?
Thanks,
-Danny
On Dec 12, 2015 1:55 PM, "jl2012--- via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It is a common practice in commercial banks that a dormant account might
> be confiscated. Confiscating or deleting dormant UTXOs might be too
> controversial, but allowing the UTXOs set growing without any limit might
> not be a sustainable option. People lose their private keys. People do
> stupid things like sending bitcoin to 1BitcoinEater. We shouldn’t be
> obliged to store everything permanently. This is my proposal:
>
> Dormant UTXOs are those UTXOs with 420000 confirmations. In every block X
> after 420000, it will commit to a hash for all UTXOs generated in block
> X-420000. The UTXOs are first serialized into the form:
> txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> After some confirmations, nodes may safely delete the UTXO records of block
> X permanently.
>
> If a user is trying to redeem a dormant UTXO, in addition the signature,
> they have to provide the scriptPubKey, height (X), and UTXO value as part
> of the witness. They also need to provide the Merkle path to the dormant
> UTXO commitment.
>
> To confirm this tx, the miner will calculate a new Merkle hash for the
> block X, with the hash of the spent UTXO replaced by 1, and commit the hash
> to the current block. All full nodes will keep an index of latest dormant
> UTXO commitments so double spending is not possible. (a "meta-UTXO set")
>
> If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> will become 1. If all dormant UTXOs in a block are spent, the record for
> this block could be forgotten. Full nodes do not need to remember which
> particular UTXO is spent or not, since any person trying to redeem a
> dormant UTXO has to provide such information.
>
> It becomes the responsibility of dormant coin holders to scan the
> blockchain for the current status of the UTXO commitment for their coin.
> They may also need to pay extra fee for the increased tx size.
>
> This is a softfork if there is no hash collision but this is a fundamental
> assumption in Bitcoin anyway. The proposal also works without segregated
> witness, just by replacing "witness" with "scriptSig"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/5df532a2/attachment.html>

2023-06-07 17:43:44

- reply

📅 Original date posted:2015-10-21
📝 Original message:A signer modifying the order of inputs or changing outputs when
"re-signing" a transaction (which already has dependent child transactions
spending its outputs) seems like quite a different hazard than a malicious
third party modifying a transaction in the mempool by twiddling opcodes in
the signature scripts. The former seems like more a matter of keeping your
own house in order (an internal affair) while the latter is an external
threat beyond the transaction writer's control.
While I agree that having a canonical ordering for inputs and outputs might
be useful in some cases, there are also use cases where the relative
positions of inputs and outputs are significant, where reordering would
change the semantics of the transaction. SIGHASH_SINGLE, for example,
makes an association between an input index and an output index. Open Asset
colored coins are identified by the order of inputs and outputs.
Let's keep canonical ordering separate from the normalized transaction ID
proposal. Baby steps. Normalized transaction IDs provide an immediate
benefit against the hazard of third party manipulation of transactions in
the mempool, even without canonical ordering.
-Danny
On Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:
> > Hm, that is true as long as the signer is the only signer of the
> > transaction, otherwise he'd be invalidating the signatures of the other
> > signers.
>
> Or he can just have the other signers re-sign with the modified version.
> Even if it only worked with a single signer, it's still a form of
> malleability
> that your BIP does not presently solve, but would be desirable to solve...
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/3ab09100/attachment.html>

2023-06-07 17:42:55

- reply

📅 Original date posted:2015-10-05
📝 Original message:What does "package" mean here?
When you say 25 txs, does that mean maximum linked chain depth, or total
number of dependent transactions regardless of chain depth?
Thanks,
-Danny
On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'd like to propose updates to the new policy limits on unconfirmed
> transaction chains.
>
> The existing limits in master and scheduled for release in 0.12 are:
> Ancestor packages = 100 txs and 900kb total size
> Descendant packages = 1000 txs and 2500kb total size
>
> Before 0.12 is released I would like to propose a significant reduction in
> these limits. In the course of analyzing algorithms for mempool limiting,
> it became clear that large packages of unconfirmed transactions were the
> primary vector for mempool clogging or relay fee boosting attacks. Feedback
> from the initial proposed limits was that they were too generous anyway.
>
> The proposed new limits are:
> Ancestor packages = 25 txs and 100kb total size
> Descendant packages = 25 txs and 100kb total size
>
> Based on historical transaction data, the most restrictive of these limits
> is the 25 transaction count on descendant packages. Over the period of
> April and May of this year (before stress tests), 5.8% of transactions
> would have violated this limit alone. Applying all the limits together
> would have affected 6.1% of transactions.
>
> Please keep in mind these are policy limits that affect transactions which
> depend on other unconfirmed transactions only. They are not a change to
> consensus rules and do not affect how many chained txs a valid block may
> contain. Furthermore, any transaction that was unable to be relayed due to
> these limits need only wait for some of its unconfirmed ancestors to be
> included in a block and then it could be successfully broadcast. This is
> unlikely to affect the total time from creation to inclusion in a block.
> Finally, these limits are command line arguments that can easily be changed
> on an individual node basis in Bitcoin Core.
>
> Please give your feedback if you know of legitimate use cases that would
> be hindered by these limits.
>
> Thanks,
> Alex
>
> On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos <morcos at gmail.com> wrote:
>
>> Thanks for everyone's review. These policy changes have been merged in
>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which
>> just implements these limits and no mempool limiting yet. The default
>> ancestor package size limit is 900kb not 1MB.
>>
>> Yes I think these limits are generous, but they were designed to be as
>> generous as was computationally feasible so they were unobjectionable
>> (since the existing policy was no limits). This does not preclude future
>> changes to policy that would reduce these limits.
>>
>>
>>
>>
>>
>> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe at gmail.com>
>> wrote:
>>
>>> The limits Alex proposed are generous (bordering on obscene!), but
>>> dropping that down to allowing only two levels of chained unconfirmed
>>> transactions is too tight.
>>>
>>> Use case: Brokered asset transfers may require sets of transactions with
>>> a dependency tree depth of 3 to be published together. ( N seller txs, 1
>>> broker bridge tx, M buyer txs )
>>>
>>> If the originally proposed depth limit of 100 does not provide a
>>> sufficient cap on memory consumption or loop/recursion depth, a depth limit
>>> of 10 would provide plenty of headroom for this 3 level use case and
>>> similar patterns.
>>>
>>> -Danny
>>>
>>> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I dont see any problem with such limits. Though, hell, if you limited
>>>> entire tx dependency trees (ie transactions and all required unconfirmed
>>>> transactions for them) to something like 10 txn, maximum two levels
>>>> deep, I also wouldnt have a problem.
>>>>
>>>> Matt
>>>>
>>>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>>>> > Hi everyone,
>>>> >
>>>> >
>>>> > I'd like to propose a new set of requirements as a policy on when to
>>>> > accept new transactions into the mempool and relay them. This policy
>>>> > would affect transactions which have as inputs other transactions
>>>> which
>>>> > are not yet confirmed in the blockchain.
>>>> >
>>>> > The motivation for this policy is 6470
>>>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit
>>>> the
>>>> > size of a mempool. As discussed in that pull
>>>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736
>>>> >,
>>>> > once the mempool is full a new transaction must be able to pay not
>>>> only
>>>> > for the transaction it would evict, but any dependent transactions
>>>> that
>>>> > would be removed from the mempool as well. In order to make sure this
>>>> > is always feasible, I'm proposing 4 new policy limits.
>>>> >
>>>> > All limits are command line configurable.
>>>> >
>>>> > The first two limits are required to make sure no chain of
>>>> transactions
>>>> > will be too large for the eviction code to handle:
>>>> >
>>>> > Max number of descendant txs : No transaction shall be accepted if it
>>>> > would cause another transaction in the mempool to have too many
>>>> > descendant transactions (all of which would have to be evicted if the
>>>> > ancestor transaction was evicted). Default: 1000
>>>> >
>>>> > Max descendant size : No transaction shall be accepted if it would
>>>> cause
>>>> > another transaction in the mempool to have the total size of all its
>>>> > descendant transactions be too great. Default : maxmempool / 200 =
>>>> 2.5MB
>>>> >
>>>> > The third limit is required to make sure calculating the state
>>>> required
>>>> > for sorting and limiting the mempool and enforcing the first 2 limits
>>>> is
>>>> > computationally feasible:
>>>> >
>>>> > Max number of ancestor txs: No transaction shall be accepted if it
>>>> has
>>>> > too many ancestor transactions which are not yet confirmed (ie, in the
>>>> > mempool). Default: 100
>>>> >
>>>> > The fourth limit is required to maintain the pre existing policy goal
>>>> > that all transactions in the mempool should be mineable in the next
>>>> block.
>>>> >
>>>> > Max ancestor size: No transaction shall be accepted if the total size
>>>> of
>>>> > all its unconfirmed ancestor transactions is too large. Default: 1MB
>>>> >
>>>> > (All limits include the transaction itself.)
>>>> >
>>>> > For reference, these limits would have affected less than 2% of
>>>> > transactions entering the mempool in April or May of this year.
>>>> During
>>>> > the period of 7/6 through 7/14, while the network was under stress
>>>> test,
>>>> > as many as 25% of the transactions would have been affected.
>>>> >
>>>> > The code to implement the descendant package tracking and new policy
>>>> > limits can be found in 6557
>>>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off of
>>>> 6470.
>>>> >
>>>> > Thanks,
>>>> > Alex
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/a1640a71/attachment.html>

2023-06-07 17:39:43

- reply

📅 Original date posted:2015-09-08
📝 Original message:What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
http://bitcoinsymbol.org/
They argue that B-with-2-vertical-bars is easily confused with the Thai
Bhat currency symbol, which is a B with a single vertical bar.
I'm not terribly fond of the B-with-horizontal-bar as a symbol, but it does
have the advantage that it is already in the Unicode glyph set, already
available on most Unicode enabled devices.
-Danny
On Sat, Sep 5, 2015 at 7:11 AM, Ken Shirriff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
> symbol isn't in the Unicode standard. To fix this, I've written a proposal
> to have the common B-with-vertical-bars bitcoin symbol added to Unicode.
> I've successfully proposed a new character for Unicode before, so I'm
> familiar with the process and think this has a good chance of succeeding.
> The proposal is at http://righto.com/bitcoin-unicode.pdf
>
> I received a suggestion to run this proposal by the bitcoin-dev group, so
> I hope this email is appropriate here. Endorsement by Bitcoin developers
> will help the Unicode Committee realize the importance of adding this
> symbol, so please let me know if you support this proposal.
>
> Thanks,
> Ken
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150908/1b167716/attachment.html>

2023-06-07 17:39:11

- reply

📅 Original date posted:2015-09-01
📝 Original message:Rather than using an inhumanly long hex string from the genesis hash to
distinguish between mainnet and testnet, why not use the network magic
bytes instead? Much shorter, just as distinct.
I'd still prefer a common network name mapping for the sake of humanity.
Few bitcoin library implementations use the same string names for mainnet
and testnet. This BIP could simply define one string name alias for each
supported network and leave mapping to local lingo to the implementors.
-Danny
On Sat, Aug 29, 2015 at 1:10 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > That's still not right, since "mainnet" and "testnet" are not host names.
> >
> > You'd have to do something like:
> >
> >
> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I would really prefer chain=<chainID> over network=<chainPetnameStr>
> By chainID I mean the hash of the genesis block, see
>
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
> I agree with Andreas Schildbach that respecting the most commonly used
> schemes is desirable.
> So my preference would be:
>
>
> /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
>
> /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> (a block in bitcoin's mainnet)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/bd5d758c/attachment.html>

2023-06-07 17:36:44

- reply

📅 Original date posted:2015-08-19
📝 Original message:>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<
Ok, glad to hear that.
>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<
I saw your post about that awhile ago, thanks for doing the work! My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.
How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?
Thanks,
-Danny
On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/dabc7a84/attachment.html>

2023-06-07 17:36:41

- reply

📅 Original date posted:2015-08-18
📝 Original message:Again, I'm not suggesting further testing in sterile environments. I'm
suggesting testing on the public global testnet network, so that real-world
hazards such as network lag, bandwidth constraints, traffic bottlenecks,
etc can wreak what havoc they can on the proposed implementation. Also, a
test deployment would give more people an opportunity to see how the
proposed implementation works and "kick the tires", which might help to
reduce some degree of angst about the proposals.
Your point appears to be that the biggest challenge facing Bitcoin is not
technical, but political. Sadly, you may be right.
On Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> People have already been testing big blocks on testnets.
>
> The biggest problem here isn’t whether we can test the code in a fairly
> sterile environment. The biggest problem is convincing enough people to
> switch without:
>
> 1) Pissing off the other side enough to the point where regardless of who
> wins the other side refuses to cooperate
> 2) Screwing up the incentive model, allowing people to sabotage the
> process somehow
> 3) Setting a precedent enabling hostile entities to destroy the network
> from within in the future
> etc…
>
> These kinds of things seem very hard to test on a testnet.
>
> On Aug 18, 2015, at 2:06 PM, Danny Thorpe <danny.thorpe at gmail.com> wrote:
>
> Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
>
> And when I refer to testnet, I mean the public global testnet blockchain,
> not in-house isolated networks like testnet-in-a-box.
>
> On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> Problem is if you know most of the people running the testnet personally
>> (as is pretty much the case with many current testnets) then the deployment
>> amounts to “hey guys, let’s install the new version”
>>
>> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Deploying experimental code onto the "live" bitcoin blockchain seems
>> unnecessarily risky. Why not deploy a blocksize limit experiment for long
>> term trials using testnet instead?
>>
>> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> As I understand, there is already a consensus among core dev that block
>>> size should/could be raised. The remaining questions are how, when, how
>>> much, and how fast. These are the questions for the coming Bitcoin
>>> Scalability Workshops but immediate consensus in these issues are not
>>> guaranteed.
>>>
>>> Could we just stop the debate for a moment, and agree to a scheduled
>>> experimental hardfork?
>>>
>>> Objectives (by order of importance):
>>>
>>> 1. The most important objective is to show the world that reaching
>>> consensus for a Bitcoin hardfork is possible. If we could have a successful
>>> one, we would have more in the future
>>>
>>> 2. With a slight increase in block size, to collect data for future
>>> hardforks
>>>
>>> 3. To slightly relieve the pressure of full block, without minimal
>>> adverse effects on network performance
>>>
>>> With the objectives 1 and 2 in mind, this is to NOT intended to be a
>>> kick-the-can-down-the-road solution. The third objective is more like a
>>> side effect of this experiment.
>>>
>>>
>>> Proposal (parameters in ** are my recommendations but negotiable):
>>>
>>> 1. Today, we all agree that some kind of block size hardfork will happen
>>> on t1=*1 June 2016*
>>>
>>> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we
>>> will adopt the backup plan
>>>
>>> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
>>> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>>>
>>> 4. If the backup plan is adopted, we all agree that a better solution
>>> should be found before t4=*31 Dec 2017*.
>>>
>>> Rationale:
>>>
>>> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
>>> prepare for a hardfork. Although we do not know what actually will happen
>>> but we know something must happen around that moment.
>>>
>>> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
>>> months after the workshops). If it is successful, we don't need to activate
>>> the backup plan
>>>
>>> t3 = 30 days is chosen to make sure every full nodes have enough time to
>>> upgrade after the actual hardfork date is confirmed
>>>
>>> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
>>> hopefully we would find a better solution. It is important to acknowledge
>>> that the backup plan is not a final solution
>>>
>>> m = 80%: We don't want a very small portion of miners to have the power
>>> to veto a hardfork, while it is important to make sure the new fork is
>>> secured by enough mining power. 80% is just a compromise.
>>>
>>> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that
>>> all types of technology has since improved by >50%. I don't mind making it
>>> a bit smaller but in that case not much valuable data could be gathered and
>>> the second objective of this experiment may not be archived.
>>>
>>> --------------------
>>>
>>> If the community as a whole could agree with this experimental hardfork,
>>> we could announce the plan on bitcoin.org and start coding of the patch
>>> immediately. At the same time, exploration for a better solution continues.
>>> If no further consensus could be reached, a new version of Bitcoin Core
>>> with the patch will be released on or before 1 Feb 2016 and everyone will
>>> be asked to upgrade immediately.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/6ce5aad3/attachment.html>

2023-06-07 17:36:40

- reply

📅 Original date posted:2015-08-18
📝 Original message:Ya, so? All that means is that the experiment might reach the hard fork
tipping point faster than mainnet would. Verifying that the network can
handle such transitions, and how larger blocks affect the network, is the
point of testing.
And when I refer to testnet, I mean the public global testnet blockchain,
not in-house isolated networks like testnet-in-a-box.
On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Problem is if you know most of the people running the testnet personally
> (as is pretty much the case with many current testnets) then the deployment
> amounts to “hey guys, let’s install the new version”
>
> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Deploying experimental code onto the "live" bitcoin blockchain seems
> unnecessarily risky. Why not deploy a blocksize limit experiment for long
> term trials using testnet instead?
>
> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As I understand, there is already a consensus among core dev that block
>> size should/could be raised. The remaining questions are how, when, how
>> much, and how fast. These are the questions for the coming Bitcoin
>> Scalability Workshops but immediate consensus in these issues are not
>> guaranteed.
>>
>> Could we just stop the debate for a moment, and agree to a scheduled
>> experimental hardfork?
>>
>> Objectives (by order of importance):
>>
>> 1. The most important objective is to show the world that reaching
>> consensus for a Bitcoin hardfork is possible. If we could have a successful
>> one, we would have more in the future
>>
>> 2. With a slight increase in block size, to collect data for future
>> hardforks
>>
>> 3. To slightly relieve the pressure of full block, without minimal
>> adverse effects on network performance
>>
>> With the objectives 1 and 2 in mind, this is to NOT intended to be a
>> kick-the-can-down-the-road solution. The third objective is more like a
>> side effect of this experiment.
>>
>>
>> Proposal (parameters in ** are my recommendations but negotiable):
>>
>> 1. Today, we all agree that some kind of block size hardfork will happen
>> on t1=*1 June 2016*
>>
>> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will
>> adopt the backup plan
>>
>> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
>> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>>
>> 4. If the backup plan is adopted, we all agree that a better solution
>> should be found before t4=*31 Dec 2017*.
>>
>> Rationale:
>>
>> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
>> prepare for a hardfork. Although we do not know what actually will happen
>> but we know something must happen around that moment.
>>
>> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
>> months after the workshops). If it is successful, we don't need to activate
>> the backup plan
>>
>> t3 = 30 days is chosen to make sure every full nodes have enough time to
>> upgrade after the actual hardfork date is confirmed
>>
>> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
>> hopefully we would find a better solution. It is important to acknowledge
>> that the backup plan is not a final solution
>>
>> m = 80%: We don't want a very small portion of miners to have the power
>> to veto a hardfork, while it is important to make sure the new fork is
>> secured by enough mining power. 80% is just a compromise.
>>
>> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all
>> types of technology has since improved by >50%. I don't mind making it a
>> bit smaller but in that case not much valuable data could be gathered and
>> the second objective of this experiment may not be archived.
>>
>> --------------------
>>
>> If the community as a whole could agree with this experimental hardfork,
>> we could announce the plan on bitcoin.org and start coding of the patch
>> immediately. At the same time, exploration for a better solution continues.
>> If no further consensus could be reached, a new version of Bitcoin Core
>> with the patch will be released on or before 1 Feb 2016 and everyone will
>> be asked to upgrade immediately.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/8eb19293/attachment.html>

2023-06-07 17:36:39

- reply

📅 Original date posted:2015-08-18
📝 Original message:Deploying experimental code onto the "live" bitcoin blockchain seems
unnecessarily risky. Why not deploy a blocksize limit experiment for long
term trials using testnet instead?
On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As I understand, there is already a consensus among core dev that block
> size should/could be raised. The remaining questions are how, when, how
> much, and how fast. These are the questions for the coming Bitcoin
> Scalability Workshops but immediate consensus in these issues are not
> guaranteed.
>
> Could we just stop the debate for a moment, and agree to a scheduled
> experimental hardfork?
>
> Objectives (by order of importance):
>
> 1. The most important objective is to show the world that reaching
> consensus for a Bitcoin hardfork is possible. If we could have a successful
> one, we would have more in the future
>
> 2. With a slight increase in block size, to collect data for future
> hardforks
>
> 3. To slightly relieve the pressure of full block, without minimal adverse
> effects on network performance
>
> With the objectives 1 and 2 in mind, this is to NOT intended to be a
> kick-the-can-down-the-road solution. The third objective is more like a
> side effect of this experiment.
>
>
> Proposal (parameters in ** are my recommendations but negotiable):
>
> 1. Today, we all agree that some kind of block size hardfork will happen
> on t1=*1 June 2016*
>
> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will
> adopt the backup plan
>
> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>
> 4. If the backup plan is adopted, we all agree that a better solution
> should be found before t4=*31 Dec 2017*.
>
> Rationale:
>
> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
> prepare for a hardfork. Although we do not know what actually will happen
> but we know something must happen around that moment.
>
> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
> months after the workshops). If it is successful, we don't need to activate
> the backup plan
>
> t3 = 30 days is chosen to make sure every full nodes have enough time to
> upgrade after the actual hardfork date is confirmed
>
> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
> hopefully we would find a better solution. It is important to acknowledge
> that the backup plan is not a final solution
>
> m = 80%: We don't want a very small portion of miners to have the power to
> veto a hardfork, while it is important to make sure the new fork is secured
> by enough mining power. 80% is just a compromise.
>
> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all
> types of technology has since improved by >50%. I don't mind making it a
> bit smaller but in that case not much valuable data could be gathered and
> the second objective of this experiment may not be archived.
>
> --------------------
>
> If the community as a whole could agree with this experimental hardfork,
> we could announce the plan on bitcoin.org and start coding of the patch
> immediately. At the same time, exploration for a better solution continues.
> If no further consensus could be reached, a new version of Bitcoin Core
> with the patch will be released on or before 1 Feb 2016 and everyone will
> be asked to upgrade immediately.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/4f1217ce/attachment-0001.html>

2023-06-07 17:36:26

- reply

📅 Original date posted:2015-08-18
📝 Original message:I like the simplicity of this approach. Demand driven response.
Is there really a need to reduce the max block size at all? It is just a
maximum limit, not a required size for every block. If a seasonal
transaction surge bumps the max block size limit up a notch, what harm is
there in leaving the max block size limit at the "high water mark"
indefinitely, even though periods of decreased transaction volume?
I'd argue to remove the reduction step, making the max block size
calculation a monotonic increasing function. Cut the complexity in half.
-Danny
On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Regarding:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>
>
> I am arguing with the following statement here...
>
> *I see problems to this approach. The biggest one I see is that a miner
>> with 11% of hash power could sabotage block size increases by only ever
>> mining empty blocks.*
>
>
>
> First, I would like to argue from economics' point of view. If someone
> wants to hold back the block size increase with 11% hash power by mining
> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
> hash power will most likely be a pool and pool miners will find out soon
> that they are losing Tx fees because of pool owner's intention. Hence,
> they'll switch pool and pool owner will lose out. This is the same reason
> why 51% attack will never happen, even if a pool gets more than 51% hash
> power.
>
>
> Next, I would like to propose a slightly modified technical solution to
> this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
> Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
> Half MaxBlockSize
> Else
> Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 50%
> hash power. Those who want to stop decrease, need to have more than 10%
> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
> this approach, not only miners, but also the end user have their say.
> Because, end users will fill up the mempool, from where miners will take Tx
> to fill up the blocks. Please note that, taking first 2000 of the last 2016
> blocks is important to avoid data discrepancy among different nodes due to
> orphan blocks. It is assumed that a chain can not be orphaned after having
> 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/c9dc8d59/attachment.html>

2023-06-07 17:35:11

- reply

📅 Original date posted:2015-08-14
📝 Original message:Any idea what's going on with TestNet? No blocks for nearly 2 hours now,
according to multiple block explorers (blockr.io, my own bitcoin node, etc).
Prior to the last block (530516), there were a lot of blocks with zero
transactions and only an occasional block with a ton of txs.
Any info?
Thx,
-Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/f3d56ba5/attachment.html>

2023-06-07 17:35:10

- reply

📅 Original date posted:2015-08-21
📝 Original message:The limits Alex proposed are generous (bordering on obscene!), but dropping
that down to allowing only two levels of chained unconfirmed transactions
is too tight.
Use case: Brokered asset transfers may require sets of transactions with a
dependency tree depth of 3 to be published together. ( N seller txs, 1
broker bridge tx, M buyer txs )
If the originally proposed depth limit of 100 does not provide a sufficient
cap on memory consumption or loop/recursion depth, a depth limit of 10
would provide plenty of headroom for this 3 level use case and similar
patterns.
-Danny
On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I dont see any problem with such limits. Though, hell, if you limited
> entire tx dependency trees (ie transactions and all required unconfirmed
> transactions for them) to something like 10 txn, maximum two levels
> deep, I also wouldnt have a problem.
>
> Matt
>
> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
> > Hi everyone,
> >
> >
> > I'd like to propose a new set of requirements as a policy on when to
> > accept new transactions into the mempool and relay them. This policy
> > would affect transactions which have as inputs other transactions which
> > are not yet confirmed in the blockchain.
> >
> > The motivation for this policy is 6470
> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the
> > size of a mempool. As discussed in that pull
> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>,
> > once the mempool is full a new transaction must be able to pay not only
> > for the transaction it would evict, but any dependent transactions that
> > would be removed from the mempool as well. In order to make sure this
> > is always feasible, I'm proposing 4 new policy limits.
> >
> > All limits are command line configurable.
> >
> > The first two limits are required to make sure no chain of transactions
> > will be too large for the eviction code to handle:
> >
> > Max number of descendant txs : No transaction shall be accepted if it
> > would cause another transaction in the mempool to have too many
> > descendant transactions (all of which would have to be evicted if the
> > ancestor transaction was evicted). Default: 1000
> >
> > Max descendant size : No transaction shall be accepted if it would cause
> > another transaction in the mempool to have the total size of all its
> > descendant transactions be too great. Default : maxmempool / 200 =
> 2.5MB
> >
> > The third limit is required to make sure calculating the state required
> > for sorting and limiting the mempool and enforcing the first 2 limits is
> > computationally feasible:
> >
> > Max number of ancestor txs: No transaction shall be accepted if it has
> > too many ancestor transactions which are not yet confirmed (ie, in the
> > mempool). Default: 100
> >
> > The fourth limit is required to maintain the pre existing policy goal
> > that all transactions in the mempool should be mineable in the next
> block.
> >
> > Max ancestor size: No transaction shall be accepted if the total size of
> > all its unconfirmed ancestor transactions is too large. Default: 1MB
> >
> > (All limits include the transaction itself.)
> >
> > For reference, these limits would have affected less than 2% of
> > transactions entering the mempool in April or May of this year. During
> > the period of 7/6 through 7/14, while the network was under stress test,
> > as many as 25% of the transactions would have been affected.
> >
> > The code to implement the descendant package tracking and new policy
> > limits can be found in 6557
> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off of
> 6470.
> >
> > Thanks,
> > Alex
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/2d59e699/attachment-0001.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-13
📝 Original message: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 <pete at 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
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/da34f3e3/attachment.html>

2023-06-07 15:36:42

- reply

📅 Original date posted:2015-06-08
📝 Original message: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 <rusty at rustcorp.com.au> wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell <rusty at rustcorp.com.au>
> Discussions-To: "Bitcoin Dev" <bitcoin-development at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/d7100388/attachment.html>

2023-06-07 15:35:42

- reply

📅 Original date posted:2015-05-26
📝 Original message: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 <pieter.wuille at gmail.com>
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....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/ac340045/attachment.html>

2023-06-07 15:35:41

- reply

📅 Original date posted:2015-05-26
📝 Original message: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 <pete at petertodd.org> 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%
>
>
> Case 3: Paying the same recipient multiple times
> ------------------------------------------------
>
> For example, consider the situation of an exchange, Acme Bitcoin Sales,
> that keeps the majority of coins in cold storage. Acme wants to move
> funds to cold storage at the lowest possible cost, taking advantage of
> periods of higher capacity. (inevitable due to the poisson nature of
> block creation) At the same time they would like to defragment their
> incoming outputs to keep redemption costs low, particularly since
> spending their high-security 3-of-7 P2SH multisigs is expensive. Acme
> creates a low fee transaction with a single output to cold storage,
> periodically adding new inputs as funds need to be moved to storage.
> Estimating the cost savings here is complex, and depends greatly on
> details of Acme's business, but regardless the approach works from a
> technical point of view. For instance if Acme's business is such that
> the total hotwallet size needed heavily depends on external factors like
> volatility, as hotwallet demand decreases throughout a day they can add
> inputs to the pending transaction. (simply asking customers to deposit
> funds directly to the cold storage is also a useful strategy)
>
> However this is another case where standard RBF is significantly more
> useful. For instance, as withdrawal requests come in the exchange can
> quickly replace their pending transactions sending funds to cold storage
> with transactions sending those funds to customers instead, each time
> avoiding multiple costly transactions. In particular, by reducing the
> need to access cold storage at all, the security of the cold-stored
> funds is increased.
>
>
> Wallet Compatibility
> --------------------
>
> All wallets should treat conflicting incoming transactions as equivalent
> so long as the transaction outputs owned by them do not change. In
> addition to compatibility with RBF-related practices, this prevents
> unnecessary user concern if transactions are mutated. Wallets must not
> assume TXIDs are fixed until confirmed in the blockchain; a fixed TXID
> is not guaranteed by the Bitcoin protocol.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000c7ea0fcac58a9d7267fef8551b9d6a5206bf42b849618cb
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/833cbbca/attachment.html>

2023-06-07 15:34:58

- reply

📅 Original date posted:2015-05-12
📝 Original message: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 <lemientelephone at gmail.com
> 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.mccorry at 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:lemientelephone at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/09f3bae2/attachment.html>

2023-06-07 15:34:31

- reply

📅 Original date posted:2015-05-26
📝 Original message: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 <pete at petertodd.org> 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
> 0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/4f1264c0/attachment.html>

2023-06-07 15:34:27

- reply

📅 Original date posted:2015-05-12
📝 Original message: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 <jim at ergophobia.org> 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*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/77139440/attachment.html>