Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Mon, May 18, 2015 at 2:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: OK. Be nice if these were cleaned up, but I guess it's a sunk cost. Yeah. On the plus side, as people spend their money, old UTXOs would be used up and then they would be included in the cost function. It is only people who are storing their money long term that wouldn't. They are unlikely to have consumed their UTXOs anyway, unless miners started paying for UTXOs. We could make it a range. UTXOs from below 355,000 and above 375,000 are included. That can create incentive problems for the next similar change, I think a future threshold is better. He said utxo_created_size not utxo_created so I assumed scriptlen? Maybe I mis-read. But you made that number up? The soft cap and hard byte limit are different beasts, so there's no need for soft cost cap hard byte limit. I was thinking about it being a soft-fork. If it was combined with the 20MB limit change, then it can be anything. I made a suggestion somewhere (her or forums not sure), that transactions should be allowed to store bytes. For example, a new opcode could be added, byte_count OP_LOCK_BYTES. This makes the transaction seem byte_count larger. However, when spending the UTXO, that transaction counts as byte_count smaller, even against the hard-cap. This would be useful for channels. If channels were 100-1000X the blockchain volume and someone caused lots of channels to close, there mightn't be enough space for all the close channel transactions. Some people might be able to get their refund transactions included in the blockchain because the timeout expires. If transactions could store enough space to be spent, then a mass channel close would cause some very large blocks, but then they would have to be followed by lots of tiny blocks. The block limit would be an average not fixed per block. There would be 3 limits Absolute hard limit (max bytes no matter what): 100MB Hard limit (max bytes after stored bytes offset): 30MB Soft limit (max bytes equivalents): 10MB Blocks lager than ~32MB require a new network protocol, which makes the hard fork even harder. The protocol change could be messages can now be 150MB max though, so maybe not so complex. This requires that transactions include scriptPubKey information when broadcasting them. Brilliant! I completely missed that possibility... I have written a BIP about it. It is still in the draft stage. I had a look into writing up the code for the protocol change. https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Thanks Stephen, I hadn't thought about BIP 34 and we need to address this in both proposals. If we can avoid it I'd like not to have one transaction hashed one way and other transactions in another way. Since BIP 34 explicitly uses the scriptSig to make the coinbase transaction unique, simply removing the scriptSig is not an option as it would potentially cause collisions. I don't remember why the scriptSig was chosen, but we also have the option of putting the blockchain height in the sequence number of the coinbase input or the locktime of the transaction, restoring the uniqueness constraint in normalized transaction IDs (for both proposals). Is there a specific reason why that was not chosen at the time? On Sat, May 16, 2015 at 5:58 AM Stephen stephencalebmo...@gmail.com wrote: We should make sure to consider how BIP34 affects normalized transaction ids, since the height of the block is included in the scriptSig ensuring that the txid will be different. We wouldn't want to enable replay attacks in the form of spending coinbase outputs in the same way they were spent from a previous block. So maybe normalized txids should strip the scriptSigs of all transactions except for coinbase transactions? This seems to make sense, since coinbase transactions are inherently not malleable anyway. Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I just wanted to add that I think even with normalized ids, it could still be useful to be able to apply these flags to choose which parts of the transaction become signed. I've also seen vague references to some kind of a merklized abstract syntax tree, but am not fully sure how that would work. Maybe someone on here could explain it? Best, Stephen On May 15, 2015, at 5:54 AM, s7r s...@sky-ip.org wrote: Hello, How will this exactly be safe against: a) the malleability of the parent tx (2nd level malleability) b) replays If you strip just the scriptSig of the input(s), the txid(s) can still be mutated (with higher probability before it gets confirmed). If you strip both the scriptSig of the parent and the txid, nothing can any longer be mutated but this is not safe against replays. This could work if we were using only one scriptPubKey per tx. But this is not enforced, and I don't think it's the proper way to do it. Something similar can be achieved if you would use a combination of flags from here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md But this has some issues too. I've read your draft but didn't understand how exactly will this prevent normal malleability as we know it, second level malleability and replays as well as how will we do the transition into mapping the txes in the blockchain to normalized txids. Looking forward to read more on this topic. Thanks for the brainstorming ;) On 5/13/2015 3:48 PM, Christian Decker wrote: Hi All, I'd like to propose a BIP to normalize transaction IDs in order to address transaction malleability and facilitate higher level protocols. The normalized transaction ID is an alias used in parallel to the current (legacy) transaction IDs to address outputs in transactions. It is calculated by removing (zeroing) the scriptSig before computing the hash, which ensures that only data whose integrity is also guaranteed by the signatures influences the hash. Thus if anything causes the normalized ID to change it automatically invalidates the signature. When validating a client supporting this BIP would use both the normalized tx ID as well as the legacy tx ID when validating transactions. The detailed writeup can be found here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. @gmaxwell: I'd like to request a BIP number, unless there is something really wrong with the proposal. In addition to being a simple alternative that solves transaction malleability it also hugely simplifies higher level protocols. We can now use template transactions upon which sequences of transactions can be built before signing them. I hesitated quite a while to propose it since it does require a hardfork (old clients would not find the prevTx identified by the normalized transaction ID and deem the spending transaction invalid), but it seems that hardforks are no longer the dreaded boogeyman nobody talks about. I left out the details of how the hardfork is to be done, as it does not really matter and we may have a good mechanism to apply a bunch of hardforks concurrently in the future. I'm sure it'll take time to implement and upgrade, but I think it would be a nice addition to the functionality and would solve a long standing problem :-) Please let me know what you think, the proposal is definitely not set in stone at this point and I'm sure
[Bitcoin-development] Bitcoin Core 0.9.5 release candidate 1 tagged
Hello, I've just tagged release candidate 1 for 0.9.5 (tag `v0.9.5rc1`). The reason for this backport release is to make BIP66 available on the 0.9 branch. This has been requested by a few users, mostly miners. Full (preliminary) release notes can be found at: https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md In contrast to 0.10.x releases it is unclear whether there will be enough gitian signatures for a binary release, any help with building is welcome. See https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-process.md (many steps have changed since then, so the release process for 0.10 or master will not work) Wladimir -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
On Tue, May 19, 2015 at 9:28 AM, Christian Decker decker.christ...@gmail.com wrote: Thanks Stephen, I hadn't thought about BIP 34 and we need to address this in both proposals. If we can avoid it I'd like not to have one transaction hashed one way and other transactions in another way. The normalized TXID cannot depend on height for other transactions. Otherwise, it gets mutated when been added to the chain, depending on height. An option would be that the height is included in the scriptSig for all transactions, but for non-coinbase transctions, the height used is zero. I think if height has to be an input into the normalized txid function, the specifics of inclusion don't matter. The previous txid for coinbases are required to be all zeros, so the normalized txid could be to add the height to the txids of all inputs. Again, non-coinbase transactions would have heights of zero. Is there a specific reason why that was not chosen at the time? I assumed that since the scriptSig in the coinbase is specifically intended to be random bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
On Tue, May 19, 2015 at 11:16 AM Tier Nolan tier.no...@gmail.com wrote: On Tue, May 19, 2015 at 9:28 AM, Christian Decker decker.christ...@gmail.com wrote: Thanks Stephen, I hadn't thought about BIP 34 and we need to address this in both proposals. If we can avoid it I'd like not to have one transaction hashed one way and other transactions in another way. The normalized TXID cannot depend on height for other transactions. Otherwise, it gets mutated when been added to the chain, depending on height. Well in the case of coinbase transactions we want them to be dependent on the height they are included in, which is not a problem since they are only valid in conjunction with the block that mined them. An option would be that the height is included in the scriptSig for all transactions, but for non-coinbase transctions, the height used is zero. No need to add an extra field to the transaction just to include the height. We can just add a rule that the height specified in the scriptSig in coinbase transactions (and only coinbase transactions) is copied into the locktime of the transaction before computing the normalized transaction ID and leave the locktime untouched for all normal transactions I think if height has to be an input into the normalized txid function, the specifics of inclusion don't matter. The previous txid for coinbases are required to be all zeros, so the normalized txid could be to add the height to the txids of all inputs. Again, non-coinbase transactions would have heights of zero. Is there a specific reason why that was not chosen at the time? I assumed that since the scriptSig in the coinbase is specifically intended to be random bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible. Sounds reasonable :-) -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report
Freundliche Grüsse --- Jonas Schnelli °° include7 AG Jonas Schnelli Mattengasse 27 CH-8005 Zürich Switzerland Office: +41 44 500 16 70 Mail: jonas.schne...@include7.ch Web: www.include7.ch V-Card: www.include7.ch/js.vcf °° ACHTUNG Bitte senden sie uns keine sensitiven Daten in unverschlüsselten E-Mails. Verwenden Sie hierzu folgenden Link: https://include7.ch/contact/secureform °° Am 18.05.2015 um 23:57 schrieb Justus Ranvier jus...@openbitcoinprivacyproject.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Replying to the list because this is a common question. We rated as many wallets as we could based on the amount of manpower we had available to perform the ratings. We will be holding a recruiting drive shortly to solicit additional volunteers so that we can cover more wallet for the next round of ratings. Hi Justus Is there a reason why Bitcoin-Core and Breadwallet (iOS) is missing? Thanks — /Jonas-- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report
Am 18.05.2015 um 23:57 schrieb Justus Ranvier jus...@openbitcoinprivacyproject.org mailto:jus...@openbitcoinprivacyproject.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Replying to the list because this is a common question. We rated as many wallets as we could based on the amount of manpower we had available to perform the ratings. We will be holding a recruiting drive shortly to solicit additional volunteers so that we can cover more wallet for the next round of ratings. Hi Justus Is there a reason why Bitcoin-Core and Breadwallet (iOS) is missing? Thanks — /Jonas Sorry for the horrible top post, i accidentally added a text signature on top. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Scaling Bitcoin with Subchains
Hi I briefly mentioned something about this on the bitcoin-dev IRC room. In general, it seems experts (like sipa i.e. Pieter) are against using sidechains as a way of scaling. As I only have a high level understanding of the Bitcoin protocol, I cannot be sure if what I want to do is actually defined as a side chain, but let me just propose it, and please let me know whether it can work, and if not why not (I'm not scared of digging into more technical resources in order to fully understand). I do have a good academic/practical background for Bitcoin, and I'm ready to contribute code if needed (one of my contributions includes a paper wallet creator written in C). The main problem I see with increasing the block size limit is that it increases the amount of storage required to fully validate all transactions for say 100 years (a person's life). With 1 MB blocks, you can store all lifetime transactions on a 5 TB drive, which basically any regular user can do. With 10 MB blocks, you need a 50 TB drive, not accessible for regular users. Yes, it's possible that in the future hard drive technology will get cheaper and smaller, but this still didn't happen, so we can't just say it should be doable at the rate of Moore's law etc..., we need to know that it is accessible for everyone, now. Also, don't forget that human life expectancy can increase with time as well. I know, it sounds silly to use a human lifetime as a measurement of how far back each user should be able to store transactions for, but what is a better measurement? This is a technology made for people i.e. humans, right, and the important part is that it is for regular people and not just well privileged people. You can search my last four emails for some more calculations. What sipa told me on the IRC channel is that Bitcoin Core does not care about old transactions. It only looks at the current blocks. Yes, that makes sense, but how do you know that your machine wasn't compromised when validating the previous blocks? And what if you want to check some old transactions (assuming you didn't index everything)? What if some of your old transaction data was lost or corrupted? I think it is clear that it is useful to be able to validate all blocks (since 100 years) rather than just a pruned part. It empowers people to have as much information about Bitcoin transactions as do large data centers; transactions that may include government or corporate corruption. This is the key to how Bitcoin enables transparency for those who should be transparent (individual users with private addresses can still remain anonymous). Also, 5 TB takes about 20 days to sync starting fresh, on a regular computer, so it allows easy entry into the system. So assuming we agree that people should be able to store ~ a lifetime of transactions, then we need 1 MB blocks. But of course, this leads to huge transaction costs, and small purchases will be out of limits. So to fix this, I propose adding a 10 1 MB chains below the main chain (sorry on the IRC room I said 10 10 MB chains by mistake), so effectively, you have a new 10 MB chain that is partitioned into 10 parts. You can also add a third level: 100 1 MB chains, and keep going like that. The idea is that when you make a large transaction, you put it through the top chain; when you make a medium sized transaction, you put it through one of the middle chains, which will be verified (mined) by the middle chain, and the top chain will verify the aggregate transactions of the middle chain. If you have a small sized transaction, you put it through one of the bottom chains, the bottom chain verifies it, the middle chain verifies the aggregate transactions of the bottom chain, and the top chain verifies the aggregate transactions of the middle chain. By aggregate transaction, I mean the net result of multiple transactions, and I suppose it can be 20 transactions belonging only to one sibling chain for level 2, or 200 transactions for level 3, etc... Now, how does the system decide to which of the 10 chains the middle sized transaction goes to? I propose just taking some simple function of the input addresses mod 10, so that you can just keep randomly generating a wallet until you get one with only addresses that map to only one of the 10 chains (even distribution), so that someone can choose one of the 10 chains, and store only the transactions that belong to that chain. They should also choose a chain from level 3, etc... So in effect, they will be storing a chain with block size O(n) where n is the number of levels. They may store multiple sibling chains at one level, if they want to track of other people's transactions, such as those of their government MP, or perhaps, they want to have a separate identity that would be more anonymous with a separate series of sibling chains. This will increase the storage size, but the increase will be proportional to the number of things you want to keep track of (at least this kind of system
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in coinbase transactions (and only coinbase transactions) is copied into
the locktime of the transaction before computing the normalized transaction
ID and leave the locktime untouched for all normal transactions
No need to replace lock times (or any other part of the transaction) at
all. If you have to, just serialize the height right before serializing the
transaction (into the same buffer). And you could pre-serialize 0 instead
of the height for all non-coinbase transactions. I don't really see what
that gets you, though, because the 0 is not really doing anything.
But, I don't see any reason you have to mess with the serialization this
much at all. Just do:
uint256 normalized_txid(CTransaction tx)
{
// Coinbase transactions are already normalized
if (!tx.IsCoinbase())
{
foreach(CTxIn in : tx.vin)
{
if (!ReplacePrevoutHashWithNormalizedHash(in.prevout))
throw NormalizationError(Could not lookup prevout);
in.scriptSig.clear();
}
}
// Serialize
CHashWriter ss(SER_GETHASH, 0);
ss tx;
return ss.GetHash();
}
An alternative could be (although I like the above option better):
uint256 normalized_txid(CTransaction tx, int nHeight)
{
foreach(CTxIn in : tx.vin)
{
if (!in.prevout.IsNull()
!ReplacePrevoutHashWithNormalizedHash(in.prevout))
throw NormalizationError(Could not lookup prevout);
in.scriptSig.clear();
}
// Serialize
CHashWriter ss(SER_GETHASH, 0);
if (tx.IsCoinbase())
ss nHeight;
// or:
// ss (tx.IsCoinbase() ? nHeight : 0);
ss tx;
return ss.GetHash();
}
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Core 0.10.2 released
-- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.10.2 released
Bitcoin Core version 0.10.2 is now available from: https://bitcoin.org/bin/bitcoin-core-0.10.2/ The distribution is also available as torrent: https://bitcoin.org/bin/bitcoin-core-0.10.2/bitcoin-0.10.2.torrent magnet:?xt=urn:btih:746a616aa8de97856c207e7a899c7ee315e8c44ddn=bitcoin-core-0.10.2tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969tr=udp%3A%2F%2Fopen.demonii.com%3A1337ws=https%3A%2F%2Fbitcoin.org%2Fbin%2 The source code can be found in git under the tag `v0.10.2`, or in `bitcoin-0.10.2.tar.gz` in the distribution. This is a new minor version release, bringing minor bug fixes and translation updates. It is only necessary to upgrade to this version when unable to start the application on Windows with 0.10.1. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading = How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Downgrade warning -- Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: * Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this. * The block index database will now hold headers for which no block is stored on disk, which earlier versions won't support. If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex. This does not affect wallet forward or backward compatibility. Notable changes === This fixes a serious problem on Windows with data directories that have non-ASCII characters (https://github.com/bitcoin/bitcoin/issues/6078). For other platforms there are no notable changes. For the notable changes in 0.10, refer to the release notes at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md 0.10.2 Change log = Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. Wallet: - `824c011` fix boost::get usage with boost 1.58 Miscellaneous: - `da65606` Avoid crash on start in TestBlockValidity with gen=1. - `424ae66` don't imbue boost::filesystem::path with locale C on windows (fixes #6078) Credits === Thanks to everyone who directly contributed to this release: - Cory Fields - Gregory Maxwell - Jonas Schnelli - Wladimir J. van der Laan And all those who contributed additional code review and/or security research: - dexX7 - Pieter Wuille - vayvanne As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). On Tue, May 19, 2015 at 1:44 PM, Wladimir J. van der Laan laa...@gmail.com wrote: -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] ChainDB Whitepaper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello all, BitPay has just released our first whitepaper on ChainDB, a new peer-to-peer database system backed by the Bitcoin blockchain. This paper outlines our intended consensus mechanism, proof of fee. Please take a look at the paper here: https://bitpay.com/chaindb.pdf We are seeking comments and feedback on this mechanism. I am happy to answer any questions about the paper itself. Sincerely, Eric Martindale -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVW2E9AAoJEHLoNvKeOhrJkLwP/1J14yGlZzddp4ApGRFsnnIz t8U9uZVvjsqxseYv6Pw3ZStQRkuBgcPDcQwMexeBi/0Z5K34LOM1565XRLtNG2sb AeLHG11ZLNK9SQSga2B0yc95uXs2Zje7Z+A+Q+h7HjhnkcQKbuLA+kB2+ZJv1CA3 dV/5A0oCMBbZukzuFkbgmnhCaNwYjWY15UbwksKb2c3ktuLxZ5zUq/ZI+W+0PZsN Px2m/qkKb0UiUfbZU5Zva8HSI8lxQrEm/dkv4voglwlG3M7fvmgXcUi+8q0VslDi 2Bx99rhpBaC79eHDUouhTNvLykP7Hal4KdyuzShlNBN+Z6AQyoeOdAQhk9YNw/iq c/tyiw6fFQVjEOJuJfetl2thByI+/hNH2m70BRXnaOtM+rQ4iIeaR7KevMi+WyYr +X9M6eqaYvkVXD1y0lEDCfsatYIhLUcXUVkM8gAdXF2yatqfCHENVYdZu9EDhYNa zC/N2akO+XNmj0a4mder3Oy0/j7vHTXq8HLHGFbCy3S3nld+A0Qe0/JTo/Vj1IZX REyBnWsaguIE8l/I/+423rzQYKlSEwP5j+V/ObTYouVCwmy+uJC8evNCI8T/APy9 Y04ocYLb2DnKLDOD8mlf+huf4x9WwK8+CdF/wm2g1SxLBchy5lkrmhbbD846HiRF m7EvzfRGI5zweCNIyx9Y =nDJ2 -END PGP SIGNATURE- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Regtest Consensus Forking Behavior Introduced in Bitcoin Core in May 2014
Hello All, Josh Rickmar and I discovered a subtle consensus change in Bitcoin Core which causes forking behavior on regtest. Luckily it does not affect mainnet or testnet, however it does mean that regtest difficulty retargetting is broken. I've made a post to the bitcointalk forums at https://bitcointalk.org/index.php?topic=1065504 for the nicer formatting which explains in detail. Regards, Dave Collins signature.asc Description: OpenPGP digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
