Re: [Bitcoin-development] Version bits proposal
Agreed, there is no need to misuse the version field as well. There is more than enough variability you could roll in the merkle tree including and excluding transactions, and the scriptSig of the coinbase transaction, which also influences the merkle root. I have a fundamental dislike of retroactively changing semantics, and the version field should be used just for that: a version. I don't even particularly like flagging support for a fork in the version field, but since I have no better solution, count me as supporting Sipa's proposal. We definitely need a more comfortable way of rolling out new features. Regards, Chris On Thu, May 28, 2015 at 3:08 AM Patrick Strateman patrick.strate...@gmail.com wrote: There is absolutely no reason to do this. Any reasonable micro-controller can build merkle tree roots significantly faster than is necessary. 1 Th/s walks the nonce range once every 4.3ms. The largest valid merkle trees are 14 nodes high. That translates to 28 SHA256 ops per 4.3ms or 6511 SHA256 ops/second. For reference an RPi 1 model B does 2451050 SHA256 ops/second. On 05/27/2015 03:52 PM, Sergio Lerner wrote: I like the idea but I think we should leave at least 16 bits of the version fixed as an extra-nonce. If we don't then miners may use them as a nonce anyway, and mess with the soft-fork voting system. My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102 Best regards -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
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] [BIP] Normalized Transaction IDs
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep referencing using hashes of complete transactions (including signatures), while the OP_CHECKAWESOMESIG looks up the previous transaction (which we already need to do anyway in order to insert the prevOut pubkeyScript), normalizes the prevout and calculates its normalized transaction ID. It then inserts the normalized transaction IDs in the OutPoint before calculating its own hash which is then signed. Is that correct so far? Let me try to summarize the discussion so far: I think we have consensus that transaction malleability needs to be addressed, and normalized transaction IDs seem to be the way to go forward. The discussion now is how to use normalized transaction IDs and we have two approaches to implement them: - OP_CHECKAWESOMESIG which continues to use the current hashes to reference a specific signed instance of a class of semantically identical transactions. Internally only the semantic class is enforced. Transactions can be fixed to reference the correct signed instance if the transaction has been changed along the way.is a softfork using the if I don't know this opcode the TX is automatically valid trick On Thu, May 14, 2015 at 2:40 AM Pieter Wuille pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote: On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com wrote: This was what I was suggesting all along, sorry if I wasn't clear. That's great. So, basically the multi-level refund problem is solved by this? Yes. So to be clear, I think there are 2 desirable end-goal proposals (ignoring difficulty of changing things for a minute): * Transactions and blocks keep referring to other transactions by full txid, but signature hashes are computed off normalized txids (which are recursively defined to use normalized txids all the way back to coinbases). Is this what you are suggesting now as well? * Blocks commit to full transaction data, but transactions and signature hashes use normalized txids. The benefit of the latter solution is that it doesn't need fixing up transactions whose inputs have been malleated, but comes at the cost of doing a very invasive hard fork. -- Pieter -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [BIP] Normalized Transaction IDs
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 we can improve it further. Regards, Christian -- 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 Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 11:04 AM, Christian Decker decker.christ...@gmail.com wrote: If the inputs to my transaction have been long confirmed I can be reasonably safe in assuming that the transaction hash does not change anymore. It's true that I have to be careful not to build on top of transactions that use legacy references to transactions that are unconfirmed or have few confirmations, however that does not invalidate the utility of the normalized transaction IDs. Sufficient confirmations help of course, but make systems like this less useful for more complex interactions where you have multiple unconfirmed transactions waiting on each other. I think being able to rely on this problem being solved unconditionally is what makes the proposal attractive. For the simple cases, see BIP62. If we are building a long running contract using a complex chain of transactions, or multiple transactions that depend on each other, there is no point in ever using any malleable legacy transaction IDs and I would simply stop cooperating if you tried. I don't think your argument applies. If we build our contract using only normalized transaction IDs there is no way of suffering any losses due to malleability. The reason I mentioned the confirmation is that all protocols I can think of start by collaboratively creating a transaction that locks in funds into a multisig output, that is committed to the blockchain. Starting from this initial setup transaction would be using normalized transaction IDs, therefore not be susceptible to malleability. I remember reading about the SIGHASH proposal somewhere. It feels really hackish to me: It is a substantial change to the way signatures are verified, I cannot really see how this is a softfork if clients that did not update are unable to verify transactions using that SIGHASH Flag and it is adding more data (the normalized hash) to the script, which has to be stored as part of the transaction. It may be true that a node observing changes in the input transactions of a transaction using this flag could fix the problem, however it requires the node's intervention. I think you misunderstand the idea. This is related, but orthogonal to the ideas about extended the sighash flags that have been discussed here before. All it's doing is adding a new CHECKSIG operator to script, which, in its internally used signature hash, 1) removes the scriptSigs from transactions before hashing 2) replaces the txids in txins by their ntxid. It does not add any data to transactions, and it is a softfork, because it only impacts scripts which actually use the new CHECKSIG operator. Wallets that don't support signing with this new operator would not give out addresses that use it. In that case I don't think I heard this proposal before, and I might be missing out :-) So if transaction B spends an output from A, then the input from B contains the CHECKSIG operator telling the validating client to do what exactly? It appears that it wants us to go and fetch A, normalize it, put the normalized hash in the txIn of B and then continue the validation? Wouldn't that also need a mapping from the normalized transaction ID to the legacy transaction ID that was confirmed? A client that did not update still would have no clue on how to handle these transactions, since it simply does not understand the CHECKSIG operator. If such a transaction ends up in a block I cannot even catch up with the network since the transaction does not validate for me. Could you provide an example of how this works? Compare that to the simple and clean solution in the proposal, which does not add extra data to be stored, keeps the OP_*SIG* semantics as they are and where once you sign a transaction it does not have to be monitored or changed in order to be valid. OP_*SIG* semantics don't change here either, we're just adding a superior opcode (which in most ways behaves the same as the existing operators). I agree with the advantage of not needing to monitor transactions afterwards for malleated inputs, but I think you underestimate the deployment costs. If you want to upgrade the world (eventually, after the old index is dropped, which is IMHO the only point where this proposal becomes superior to the alternatives) to this, you're changing *every single piece of Bitcoin software on the planet*. This is not just changing some validation rules that are opt-in to use, you're fundamentally changing how transactions refer to each other. As I mentioned before, this is a really long term strategy, hoping to get the cleanest and easiest solution, so that we do not further complicate the inner workings of Bitcoin. I don't think that it is completely out of question to eventually upgrade to use normalized transactions, after all the average lifespan of hardware is a few years tops. Also, what do blocks
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Glad you like it, I was afraid that I missed something obvious :-)
The points the two of you raised are valid and I will address them as soon
as possible. I certainly will implement this proposal so that it becomes
more concrete, but my C++ is a bit rusty and it'll take some time, so I
wanted to gauge interest first.
This has the effect of doubling the size of the UTXO database. At
minimum, there needs to be a legacy txid to normalized txid map in the
database.
An addition to the BIP would eliminate the need for the 2nd index. You
could require a SPV proof of the spending transaction to be included with
legacy transactions. This would allow clients to verify that the
normalized txid matched the legacy id.
The OutPoint would be {LegacyId | SPV Proof to spending tx | spending tx
| index}. This allows a legacy transaction to be upgraded. OutPoints
which use a normalized txid don't need the SPV proof.
It does and I should have mentioned it in the draft, according to my
calculations a mapping legacy ID - normalized ID is about 256 MB in size,
or at least it was at height 330'000, things might have changed a bit and
I'll recompute that. I omitted the deprecation of legacy IDs on purpose
since we don't know whether we will migrate completely or leave keep both
options viable.
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think both IDs can be used in the merkle tree, since we lookup an ID in
both indices we can use both to address them and we will find them either
way.
As for the opcodes I'll have to check, but I currently don't see how they
could be affected. The OP_*SIG* codes calculate their own (more
complicated) stripped transaction before hashing and checking the
signature. The input of the stripped transaction simply contains whatever
hash was used to reference the output, so we do not replace IDs during the
operation. The stripped format used by OP_*SIG* operations does not have to
adhere to the hashes used to reference a transaction in the input.
I think there might actually be two or three or four BIPs here:
+ Overall what is trying to be accomplished
+ Changes to the OP_*SIG* opcodes
+ Changes to the bloom-filtering SPV support
+ ...eventually, hard fork rollout plan
I also think that it is a good idea to have actually implemented a
proposal before getting a BIP number. At least, I find that actually
writing the code often turns up issues I hadn't considered when thinking
about the problem at a high level. And I STRONGLY believe BIPs should be
descriptive (here is how this thing works) not proscriptive (here's how
I think we should all do it).
We can certainly split the proposal should it get too large, for now it
seems manageable, since opcodes are not affected. Bloom-filtering is
resolved by adding the normalized transaction IDs and checking for both IDs
in the filter. Since you mention bundling the change with other changes
that require a hard-fork it might be a good idea to build a separate
proposal for a generic hard-fork rollout mechanism.
If there are no obvious roadblocks and the change seems generally a good
thing I will implement it in Bitcoin Core :-)
Regards,
Chris
On Wed, May 13, 2015 at 3:44 PM Gavin Andresen gavinandre...@gmail.com
wrote:
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?
I think there might actually be two or three or four BIPs here:
+ Overall what is trying to be accomplished
+ Changes to the OP_*SIG* opcodes
+ Changes to the bloom-filtering SPV support
+ ...eventually, hard fork rollout plan
I also think that it is a good idea to have actually implemented a
proposal before getting a BIP number. At least, I find that actually
writing the code often turns up issues I hadn't considered when thinking
about the problem at a high level. And I STRONGLY believe BIPs should be
descriptive (here is how this thing works) not proscriptive (here's how
I think we should all do it).
Finally: I like the idea of moving to a normalized txid. But it might make
sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg
Maxwell's excellent talk about his current thoughts on that topic:
https://www.youtube.com/watch?v=Gs9lJTRZCDc
On Wed, May 13, 2015 at 9:12 AM, Tier Nolan tier.no...@gmail.com wrote:
I think this is a good way to handle things, but as you say, it is a hard
fork.
CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.
This has the effect of doubling the size of the UTXO database. At
minimum, there needs to be a legacy txid to normalized txid
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
If the inputs to my transaction have been long confirmed I can be reasonably safe in assuming that the transaction hash does not change anymore. It's true that I have to be careful not to build on top of transactions that use legacy references to transactions that are unconfirmed or have few confirmations, however that does not invalidate the utility of the normalized transaction IDs. The resource doubling is not optimal, I agree, but compare that to dragging around malleability and subsequent hacks to sort-of fix it forever. Additionally if we were to decide to abandon legacy transaction IDs we could eventually drop the legacy index after a sufficient transition period. I remember reading about the SIGHASH proposal somewhere. It feels really hackish to me: It is a substantial change to the way signatures are verified, I cannot really see how this is a softfork if clients that did not update are unable to verify transactions using that SIGHASH Flag and it is adding more data (the normalized hash) to the script, which has to be stored as part of the transaction. It may be true that a node observing changes in the input transactions of a transaction using this flag could fix the problem, however it requires the node's intervention. Compare that to the simple and clean solution in the proposal, which does not add extra data to be stored, keeps the OP_*SIG* semantics as they are and where once you sign a transaction it does not have to be monitored or changed in order to be valid. There certainly are merits using the SIGHASH approach in the short term (it does not require a hard fork), however I think the normalized transaction ID is a cleaner and simpler long-term solution, even though it requires a hard-fork. Regards, Christian On Wed, May 13, 2015 at 7:14 PM Pieter Wuille pieter.wui...@gmail.com wrote: Normalized transaction ids are only effectively non-malleable when all inputs they refer to are also non-malleable (or you can have malleability in 2nd level dependencies), so I do not believe it makes sense to allow mixed usage of the txids at all. They do not provide the actual benefit of guaranteed non-malleability before it becomes disallowed to use the old mechanism. That, together with the +- resource doubling needed for the UTXO set (as earlier mentioned) and the fact that an alternative which is only a softfork are available, makes this a bad idea IMHO. Unsure to what extent this has been presented on the mailinglist, but the softfork idea is this: * Transactions get 2 txids, one used to reference them (computed as before), and one used in an (extended) sighash. * The txins keep using the normal txid, so not structural changes to Bitcoin. * The ntxid is computed by replacing the scriptSigs in inputs by the empty string, and by replacing the txids in txins by their corresponding ntxids. * A new checksig operator is softforked in, which uses the ntxids in its sighashes rather than the full txid. * To support efficiently computing ntxids, every tx in the utxo set (currently around 6M) stores the ntxid, but only supports lookup bu txid still. This does result in a system where a changed dependency indeed invalidates the spending transaction, but the fix is trivial and can be done without access to the private key. On May 13, 2015 5:50 AM, Christian Decker decker.christ...@gmail.com 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
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
The propagation speed gain from having smaller blocks is linear in the size reduction, down to a small size, after which the delay of the first byte prevails [1], however the blockchain fork rate increases superlinearly, giving an overall worse tradeoff. A high blockchain fork rate is a symptom of inefficient use of the network's mining resources and may give an advantage to an attacker that is more efficient in communicating internally. I'd strongly against increasing the block generation rate in Bitcoin, it'd be a very controversial proposal and would not solve anything. [1] http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf On Mon, May 11, 2015 at 1:51 PM Dave Hudson d...@hashingit.com wrote: On 11 May 2015, at 12:10, insecurity@national.shitposting.agency wrote: On 2015-05-11 10:34, Peter Todd wrote: How do you see that blacklisting actually being done? Same way ghash.io was banned from the network when used Finney attacks against BetCoin Dice. As Andreas Antonopoulos says, if any of the miners do anything bad, we just ban them from mining. Any sort of attack like this only lasts 10 minutes as a result. Stop worrying so much. This doesn't work because a large-scale miner can trivially make themselves look like a very large number of much smaller scale miners. Their ability to minimize variance comes from the cumulative totals they control so 10 pools of 1% of the network cumulatively have the same variance as 1 pool with 10% of the network. It's also very easy for miners to relay blocks via different addresses and the cost is minimal. The biggest cost would be in DDoS prevention and a miner that actually split their pool into lots of small fragments would actually give themselves the ability to do quite a lot of DDoS mitigation anyway. If no-one is doing this right now it's simply because they've not had the right incentives to make it worthwhile; if the incentives make it worthwhile then this is pretty trivial to do. This is one area where anonymity on behalf of transaction validators and block makers essentially makes it pretty-much impossible to maintain any sort of sanctions against antisocial behaviour. -- 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] Area of Focus
Thanks for bringing this to my attention. I added a safety check to my crawler and seed.bitcoinstats.com should not return IPs that also run HTTP or HTTPS, hopefully this'll keep it off blacklists :-) -- Christian Decker On Sat, Dec 20, 2014 at 9:57 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: There was recently some discussion around dnsseeds. Currently some dnsseeds are getting blocked by ISPs because the hosts they pick up (which run bitcoin core nodes) often run rather web servers alongside which serve malware or whatever else and thus end up on IP-based malware blacklists. Of course we really dont want to move off of DNS because it has this big built-in anonymity network where the DNS seed servers only get information about your ISP, not you, and its cached so you dont get as much information about how many users are making those requests. A potential solution might be supporting some subdomain which has results XORed with some constant mask to tweak the real IP. Additionally, it might be cool to stuff a TXT//whatever record with a signature of the results provided by the DNSseed operator. Matt On 12/20/14 07:42, Will Bickford wrote: Hi all, I'm looking to help with Bitcoin core development in my spare time (a few hours per week). A little bit about me: * I use C++ and Qt daily * I love to automate and enhance software systems * I enjoy root causing and fixing issues I saw Gavin say we needed help with testing in a Reddit AMA a while ago. I'm curious where I can make the best impact. Any feedback would be appreciated. Thanks! Will Bickford In Google We Trust -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
I wonder whether we actually want to support this kind of advertisement in the P2P protocol. We have a working mechanism for protocol extensions in the P2P network (service flags) so this is obviously only for services that are not P2P extensions, so why have them in there at all? I'd argue that a parallel network, external to Bitcoin, could take over the task of advertising external services. Regards, Chris -- Christian Decker On Fri, Aug 8, 2014 at 11:26 AM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote: He wants to use it to advertise services that are not part of the P2P protocol itself, but run on a different port. Reserving services bits for those is not acceptable. Why not? Does the port matter much? Yes. The services bits are for advertising services on the P2P network. That's not open for discussion. It also wouldn't work. A bit is not enough to find an external service except in the naive case where the advertised service would have a fixed port. Not even bitcoind has a fixed port. So there needs to be a mechanism to find how to connect to the 'external service'. This is provided by the proposed extension. It would in principle be possible to advertise an extra service bit *in addition to* this one, to make it easier to find through the addr mechanism. But it would be confusing and IMO an abuse of P2P service bits. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
+1 for the new field, overloading fields with new meaning is definitely not a good idea. Something like nExpireAt with a block height sounds reasonable to me, but we need to document that the usual caveats with blockchain reorgs apply. On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik jgar...@bitpay.com wrote: ...because nLockTime is the exact opposite of expiration. A locked TX begins life invalid, and becomes valid (not-expired) after nLockTime passes. A new field containing expiration time would work. On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding t...@thinlink.com wrote: How is eventual expiration of a tx that started life with an nLockTime in the future breaking, any more than any other tx expiring? On 8/6/2014 6:54 AM, Mike Hearn wrote: We could however introduce a new field in a new tx version. We know we need to rev the format at some point anyway. On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik jgar...@bitpay.com wrote: ...and existing users and uses of nLockTime suddenly become worthless, breaking payment channel refunds and other active uses of nLockTime. You cannot assume the user is around to rewrite their nLockTime, if it fails to be confirmed before some arbitrary deadline being set. On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding t...@thinlink.com wrote: ... If nLockTime is used for expiration, transaction creator can't lie to help tx live longer without pushing initial confirmation eligibility into the future. Very pretty. It would also enable fill or kill transactions with a backdated nLockTime, which must be confirmed in a few blocks, or start vanishing from mempools. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Policy for DNS seeds
How about research projects into node distribution? Specifically I wonder whether the collection and analysis of DNS query origin is allowed when queries are anonymized and aggregated. This would prevent the identification of a single user, which I assume is the rationale for point 4. Other than that I'm perfectly fine with accepting the rules for seed.bitcoinstats.com Regards, Christian -- Christian Decker On Mon, Jul 21, 2014 at 2:43 PM, Wladimir laa...@gmail.com wrote: We've established a few basic rules for the DNS seeds as used in the Bitcoin Core software. See below. If you run one of the DNS seeds please reply to this and let us know whether you agree to these terms. if you think some requirements are unreasonable let us know too. If we haven't heard from you by 2014-08-04 we will remove your DNS seed from the list of defaults. Expectations for DNSSeed operators Bitcoin Core attempts to minimize the level of trust in DNS seeds, but DNS seeds still pose a small amount of risk for the network. Other implementations of Bitcoin software may also use the same seeds and may be more exposed. In light of this exposure this document establishes some basic expectations for the expectations for the operation of dnsseeds. 0. A DNSseed operating organization or person is expected to follow good host security practices and maintain control of their serving infrastructure and not sell or transfer control of their infrastructure. Any hosting services contracted by the operator are equally expected to uphold these expectations. 1. The DNSseed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operators understanding and capability. 2. For the avoidance of doubt, the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed. 3. The results may not be served with a DNS TTL of less than one minute. 4. Any logging of DNS queries should be only that which is necessary for the operation of the service or urgent health of the Bitcoin network and must not be retained longer than necessary or disclosed to any third party. 5. Information gathered as a result of the operators node-spidering (not from DNS queries) may be freely published or retained, but only if this data was not made more complete by biasing node connectivity (a violation of expectation (1)). 6. Operators are encouraged, but not required, to publicly document the details of their operating practices. 7. A reachable email contact address must be published for inquiries related to the DNSseed operation. If these expectations cannot be satisfied the operator should discontinue providing services and contact the active Bitcoin Core development team as well as posting on bitcoin-development. Behavior outside of these expectations may be reasonable in some situations but should be discussed in public in advance. See https://github.com/bitcoin/bitcoin/pull/4566 Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
The domain bitcoin.org resolves to that IP address. Could it be some update check together with a circular redirect? That could at least explain the large number of connection attempts. -- Christian Decker On Sun, Mar 2, 2014 at 9:56 PM, Wladimir laa...@gmail.com wrote: On Sun, Mar 2, 2014 at 7:34 PM, James Hartig fastest...@gmail.com wrote: Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Sounds very unlikely that bitcoind would connect to port 443, let alone 'attack' anything. Anything in debug.log regarding that IP? Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Network propagation speeds
Damn, that happens if I do the overview as an afterthought. Fixed :-) Real time (last 24 hours, last week, last month) are in the pipeline, just need to find the time to implement access to the collector from the webpage. -- Christian Decker On Wed, Nov 27, 2013 at 8:35 PM, Mike Hearn m...@plan99.net wrote: Hey Christian, Could you sort the snapshots by date? At the moment they're kind of in a random order. Sometimes I wish we had real-time stats too but this is a great start. On Mon, Nov 25, 2013 at 8:27 PM, Christian Decker decker.christ...@gmail.com wrote: Thanks Mike for the Tip :-) I will definitely extend the calculations to include a size-normalized version. As for transaction propagations, being much smaller the measurements tend to be much noisier, but given enough samples we might be able to reconstruct some of the system parameters. Good idea to attempt to correlate propagation speed and number of inputs/outputs, might be interesting to see whether processing at the nodes has an influence. Regards, Chris -- Christian Decker On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager grona...@ceptacle.com wrote: Hi Christian, Cool - thanks for posting - agree, that it would be nice to normalize the results with block size - so divide by size and: 1. see if there is a correlation (we all presume there still is) 2. plot the delay graph as e.g. normalized to the averaged blocksize or lets define a standard block size of 200kb or what ever so we can compare the plot btw days. Also, does the correlation of propagation times hold for transaction sizes as well (would be ice to find the logical t0 and the constant - I guess the interesting measure is not kb but signatures, so number of inputs - some correlation with size though). Best, Michael On 24/11/13, 17:37 , Christian Decker wrote: Sure thing, I'm looking for a good way to publish these measurements, but I haven't found a good option yet. They are rather large in size, so I'd rather not serve them along with the website as it hasn't got the capacity. Any suggestions? If the demand is not huge I could provide them on a per user basis. -- Christian Decker On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker decker.christ...@gmail.com wrote: Since this came up again during the discussion of the Cornell paper I thought I'd dig up my measurement code from the Information Propagation paper and automate it as much as possible. Could you publish the block ids and timestamp sets for each block? It would be useful in correlating propagation information against block characteristics. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP
Re: [Bitcoin-development] Network propagation speeds
Thanks Mike for the Tip :-) I will definitely extend the calculations to include a size-normalized version. As for transaction propagations, being much smaller the measurements tend to be much noisier, but given enough samples we might be able to reconstruct some of the system parameters. Good idea to attempt to correlate propagation speed and number of inputs/outputs, might be interesting to see whether processing at the nodes has an influence. Regards, Chris -- Christian Decker On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager grona...@ceptacle.com wrote: Hi Christian, Cool - thanks for posting - agree, that it would be nice to normalize the results with block size - so divide by size and: 1. see if there is a correlation (we all presume there still is) 2. plot the delay graph as e.g. normalized to the averaged blocksize or lets define a standard block size of 200kb or what ever so we can compare the plot btw days. Also, does the correlation of propagation times hold for transaction sizes as well (would be ice to find the logical t0 and the constant - I guess the interesting measure is not kb but signatures, so number of inputs - some correlation with size though). Best, Michael On 24/11/13, 17:37 , Christian Decker wrote: Sure thing, I'm looking for a good way to publish these measurements, but I haven't found a good option yet. They are rather large in size, so I'd rather not serve them along with the website as it hasn't got the capacity. Any suggestions? If the demand is not huge I could provide them on a per user basis. -- Christian Decker On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker decker.christ...@gmail.com wrote: Since this came up again during the discussion of the Cornell paper I thought I'd dig up my measurement code from the Information Propagation paper and automate it as much as possible. Could you publish the block ids and timestamp sets for each block? It would be useful in correlating propagation information against block characteristics. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Network propagation speeds
Since this came up again during the discussion of the Cornell paper I thought I'd dig up my measurement code from the Information Propagation paper and automate it as much as possible. The result is the Network Propagation page on bitcoinstats.com (http://bitcoinstats.com/network/propagation/). It takes a daily snapshot of the situation, then calculates the time until blocks and transactions reach a certain percentile of the nodes in the network. There is also a detailed page showing the density function describing at what times nodes learn about the existence of a block/transaction (for example yesterdays distribution: http://bitcoinstats.com/network/propagation/2013/11/23). I intend to add more information and plots over time, but I wanted to push this out quickly as there were some people asking for it. Hope this helps getting the blockchain fork rate down :-) Regards, Chris -- Christian Decker -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Network propagation speeds
Sure thing, I'm looking for a good way to publish these measurements, but I haven't found a good option yet. They are rather large in size, so I'd rather not serve them along with the website as it hasn't got the capacity. Any suggestions? If the demand is not huge I could provide them on a per user basis. -- Christian Decker On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker decker.christ...@gmail.com wrote: Since this came up again during the discussion of the Cornell paper I thought I'd dig up my measurement code from the Information Propagation paper and automate it as much as possible. Could you publish the block ids and timestamp sets for each block? It would be useful in correlating propagation information against block characteristics. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
I'd like to add some historical background about how the protocol specification came to be in the first place. A bit over three years [1] ago I started an attempt to document the network protocol, by reverse engineering it from the satoshi client. My goal, back then, was to enable like-minded engineers to create alternative clients and move away from the client-monoculture that is still predominant today. It was clear from the beginning that it would merely be a reverse engineering effort, and that it would likely lag a bit behind the changes in the main client. It was meant as a help for engineers that are not well versed in C/C++ to enable them to contribute by creating new clients, but the satoshi client would always be the de-facto standard. With the move from Google Code to the Bitcoin.it wiki somehow this notion of it being a reverse engineering effort was lost and people started assuming that if the behavior of the satoshi client did not match the protocol description it was a bug on the client side. Instead it is because the reverse engineering of the protocol is incorrect or simply missing some details. Although the protocol description is far more complete than it was back when we started, I still don't feel comfortable giving it the name specification. I still believe that a client monoculture is bad for the system as a whole, because a single bug might bring down the whole network. Giving people the necessary tools to implement new clients brings stability. I do understand the criticism that writing a specification might hinder future development as it restricts the possible changes to the protocol, but isn't this already the case as long as we have legacy versions of the client participating in the network? I would also argue that having a specification allows an application independent review of the protocol to identify possible improvements and bugs. I think the protocol description has an important place in the development of Bitcoin, so much so that we pushed a long time ago to separate protocol version from the client version. I would love to see the protocol specification becoming official part of the bitcoin github repository, which would ideally be maintained alongside the satoshi client to keep it up to date. Regards, Christian Decker [1] https://bitcointalk.org/index.php?topic=231 -- Christian Decker On Thu, Oct 24, 2013 at 9:03 AM, Martin Sustrik sust...@250bpm.com wrote: On 23/10/13 23:07, Pieter Wuille wrote: In short, consistency is more important than correctness. That's a nice and concise way to put it and any potential protocol documentation should start with a statement like that. However, I do not think that making it hard to find information about the details of the system is the way to go. Alternate implementations are likely inevitable, and in the long run probably a win for the ecosystem. If effort is put into accurately describing the rules, it should indeed carry a strong notice about it being descriptive rather than normative. One interesting question is whather alternative implementations are more likely to get it wrong because the protocol description is wrong or because the authors misunderstood the reference implementation source code. Extensive documentation of the source code, a la Knuth's literate programming, may be some kind of a middle ground. If someone is willing to work on that, I am (and likely many people in #bitcoin-dev are) available for any questions about the protocol and its semantics. Ok. Several people expressed an interest in the topic, so I'll give it a try and see how it fares. Martin -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
Just a quick and dirty check if something bad actually happened. 430 transactions that were confirmed in the alt-chain, are not confirmed in the true blockchain. The good news is that as far as I can tell most of them are low volume transactions destined for SD. 7 transactions were true double spends, or to be more precise transactions in which an conflicting transaction was confirmed in the new chain (with their respective amount): 12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 261 BTC cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af 0.06 BTC 7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96 0.01 BTC 355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e 0.05 BTC b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a 0.61 BTC 138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6 1.62 BTC a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90 0.81 So the one transaction that really hurt was the one published on BitcoinTalk. We're not yet out of the woods as some of the 423 transactions still have a chance of being doublespent, but looks like it's not that bad after all. Cheers, Chris P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln -- Christian Decker On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. [snip] I agree it would be good to confirm no one was ripped off, even though we can't say there weren't any attempts. https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hosting of compiled bitcoin client
Being an international team I'm pretty sure we can find someone who is in a more permissive country. Would someone knowledgeable point us to the specific laws, so that we can look it up in our respective jurisdiction? Regards, Chris On Mon, Oct 15, 2012 at 12:02 AM, Luke-Jr l...@dashjr.org wrote: On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote: Given that sourceforge has shown to restrict access to a number of countries at the request of the USA This needs some clarification. If the USA has requested it, then presumably there's some legality involved, and our US developers shouldn't be made liable for it. The specific reason SourceForge has restricted access should be made known so non-US developers (or gitian builders) can evaluate their own laws and hopefully at least one will be in a jurisdiction that allows it. But GitHub is also US-located, so hosting it there may be a problem too. Luke -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?
It can speed up the initial chain download. A newly created wallet will have only new key-pairs, hence no incoming transactions (unless we have a key collision, which is unlikely). So there is no need for a bootstrapping node to download the chain with transactions. The chain itself can be verified without the transactions. Later full blocks would be required to detect usable inputs for future outgoing transactions. As long as you verify the very last blocks in the chain you can be sure that all preceeding blocks were also valid. HTH, Chris On Mon, Jan 2, 2012 at 6:04 AM, Elden Tyrell tyrell.el...@gmail.com wrote: Satoshi's paper mentions that storage requirements for the blockchain can be reduced by deleting transactions whose outputs have been spent. If I understand correctly, this technique can only be used for reducing *storage* requirements, not *bandwidth* needed for the initial chain download by a high-security client that doesn't trust any of its peers -- right? The rule is trust the longest valid chain of blocks. Part of a block being valid is that each transaction's inputs are unspent and their sum exceeds the transaction's outputs unless it is a coinbase. This cannot be verified for stubbed out transactions -- they have outputs but no inputs, and aren't coinbases. So a paranoid client booting up for the first time needs to be given an un-stubbed chain, right? Of course, if a client decided to accept a stubbed blocks only when the sum of the difficulties in the blocks after it exceeds some number N, then attacking it could be made very expensive by picking a large enough N. Please let me know if I have misunderstood something. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
First of all I do agree that a method for adjusting the difficulty in a huge power drop is needed (I don't see it so much in power rises). The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. Regards, Chris 2011/11/23 Jorge Timón timon.elvi...@gmail.com With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? 2011/11/23, Andy Parkins andypark...@gmail.com: On 2011 November 23 Wednesday, Jorge Timón wrote: 2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Just as with the current system. The defence is that on receipt of a block, its timestamp is checked against the node's own clock and averaged network clock. Blocks out of that band are rejected. Andy -- Dr Andy Parkins andypark...@gmail.com -- Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
Just brainstorming here, no idea if this would work: - Pick any old block - Create a chain fork by creating simpler blocks on top of your chosen one - The chain will not be accepted by others - At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network - Suddenly all your blocks are valid and you force people to switch to your forked chain If this is possible it would allow you to revoke all transactions and claim all the mined coins since you forked. My point is that the notion of hardest chain is not so simple. The difficulty of invalidating a chain is dramatically reduced with your time window approach, by not requiring a given difficulty, and relying on synchronized time windows. Regards, Chris On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins andypark...@gmail.com wrote: On 2011 November 23 Wednesday, Christian Decker wrote: The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. These are reasonable objections. My counter is this: Let's view block difficulty as a measure of time, not time itself. The timestamp is merely a convenience for the block. You cannot fake the computing power needed for a particular difficulty; so the hardest chain always wins (note: hardest chain). If I am a miner, I have two choices: (a) try to replace the top block on the current hardest chain (b) try to append to the current hardest chain Either of these is acceptable; but in case (a) I have to generate a more difficult block to replace it; in case (b), at the start of the window, any difficulty is acceptable (however, I'm competing with other miners, so _any_ difficulty won't beat them). The rule then is that you're trying to win the one block reward that is available every 10 minutes; and your peers will be rejecting blocks with timestamps that are lies. Perhaps an example... - I (a node), download the blockchain - The blockchain has N potential heads. Each of those heads has a time, t and a sum_of_difficulty. - The next block reward is going to go to the highest difficulty with t timestamp (t + T) _and_ verified timestamp (i.e. not received more than, say 5 minutes, from its claimed timestamp). - I can choose any head to start generating from, but given that it's the highest difficulty chain that's going to win the next reward (not the highest difficulty block), I will surely pick the most difficult? - A rogue miner then issues a block with a fake timestamp; it actually generated at (t + T + 5) but claims (t + 5). Should I start using that block as my new head? Obviously not, because my peers might decide that it is a lie and reject it because it was received too late, making my work useless. It is in my interest to pick a head that is honest. Resolving forks is easy: - 50 coins every ten minutes only - most difficult chain wins I'm certainly not saying it's a simple change. There are certainly areas I haven't thought about, and could be game-overs; but I do like the idea of there being no target difficulty, and instead the blocks are issued at a fixed ten minute rate (or rather the rewards are). Andy -- Dr Andy Parkins andypark...@gmail.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk
Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent
Same here of course, but I'll keep the String short and fixed. I still don't think there should be any reason for others to know my OS in order to communicate with me :-) On Mon, Nov 14, 2011 at 9:48 AM, Stefan Thomas m...@justmoon.de wrote: Nice. I'll check with justmoon when I hopefully meet him at the conference. It's all fine with me. As soon as the original client switches to the new format, we will, too. On 11/13/2011 09:52 PM, Amir Taaki wrote: Nice. I'll check with justmoon when I hopefully meet him at the conference. If all is OK, hopefully 0.6 will be the last protocol version bump for a while. -- *From:* Mike Hearn m...@plan99.net m...@plan99.net *To:* Amir Taaki zgen...@yahoo.com zgen...@yahoo.com *Cc:* bitcoin-development@lists.sourceforge.netbitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.netbitcoin-development@lists.sourceforge.net *Sent:* Saturday, November 12, 2011 7:31 PM *Subject:* Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly. On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki zgen...@yahoo.com wrote: Hi, https://en.bitcoin.it/wiki/BIP_0014 Thanks to Gavin Andresen for proof reading and suggesting clarifications. Thanks to Patrick Strateman for suggesting the hierarchical format and pointing out some flaws of browser user-agents to me. The timeline is written in the past tense since BIPs are meant to be readable in the future for explaining why we took certain decisions with bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;) The next version 0.6 should be the protocol version which becomes peeled off from the current client. There are still some changes migrating into the protocol that need to be finished. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register nowhttp://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote: BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
Sorry for shooting this approach down, but I'm against it. User-agent strings are an extremely bad idea as it would lead developers to start making communication choices depending on the client type. User-Agents in HTTP are only useful if the clients (browsers) do not adhere to a well defined behavior. I see the version string more as a kind of vanity point (xyz peers are using my network code) and it would be bad to base choices on it. For protocol choices we already have a good mechanism in place (nServices) to negotiate capabilities. I for one vote for keeping it as simple as possible, just a simple string, without any further meaning. On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki zgen...@yahoo.com wrote: From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP): User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them. We need a hierarchy from protocol, variant, gui, flavour, build /Satoshi:314700/bitcoin-qt:0.4/ How does that sound? In BitcoinJ's case: /BitcoinJ:0.2/AndroidBuild:0.8/ Thoughts: - Do we need a freely defined comments field? /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ -- *From:* Christian Decker decker.christ...@gmail.com *To:* Mike Hearn m...@plan99.net *Cc:* Amir Taaki zgen...@yahoo.com; bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net *Sent:* Saturday, November 5, 2011 2:45 PM *Subject:* Re: [Bitcoin-development] Lock protocol version numbers On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote: BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
I don't really get what you want to achieve with this. The protocol will be slow down evolution (hopefully) soon, while the clients will continue releasing at a similar rhythm. It took long enough to decouple the protocol version from being bumped each client release, now doing the inverse coupling makes no sense. Regards, Chris On Wed, Nov 2, 2011 at 10:23 PM, Amir Taaki zgen...@yahoo.com wrote: Hey, Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds? Satoshi 0.4 BitcoinJava 120311 bitcoin-js 6 Like so. Otherwise we will have version bumping insanity :) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
Just for reference: https://github.com/bitcoin/bitcoin/pull/63 The issue resulted in my most useless pull request fixing two variables :-) I second the use of sub_version_num as a Client and Version identifier. Regards, Chris On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki zgen...@yahoo.com wrote: Point taken. About the sub_version_num though. I prefer to let the field by defined clients however they wish, with just a guideline suggestion that IDENTIFIER VERSION is a format they should follow. The idea being that different projects would have different release scheduling schemes and it'd be restrictive to lock people into the popular major.minor system. So for the current bitcoin to find out the version number of other clients (if it was needed), it would have to parse the number from the string: Satoshi 0.5 Although there would be little reason for this with a sane protocol versioning scheme. If we're agreed then I'll start on that BIP. -- *From:* Gavin Andresen gavinandre...@gmail.com *To:* Amir Taaki zgen...@yahoo.com *Sent:* Wednesday, November 2, 2011 9:34 PM *Subject:* Re: [Bitcoin-development] Lock protocol version numbers Good idea. Sounds perfect for a BIP On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki zgen...@yahoo.com wrote: Hey, Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds? -- -- Gavin Andresen -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters ampe...@gmail.com wrote: • I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out. ACK Does it have to be wiki pages if we're going through an editorial process anyway, and there will be few who can actually edit the pages directly? I'd go for simple HTML documents in a repository. • If he's willing, I propose that Amir take the role of BIP editor. ACK ACK • I think bitcoin is still too small to have a specialized bitcoin-ideas mailing list; I propose that new potential BIPs be discussed either here or on the bitcoin-dev mailing list. ACK Definitely. I don't think too many requests will come right away, and by posting them here we make sure that the most knowledgeable people are there to check and improve what might eventually end up in the clients. As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to have started a few proposals at https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the right direction to head in, and a composite list of similar proposals could be maintained on their own repository (to maintain separation from the core Bitcoin repo.) -Alex -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Help wanted: translations
Damn, german is already contributed :-) Well I can still do the italian one and check german then. On Sat, Oct 8, 2011 at 11:13 PM, Gavin Andresen gavinandre...@gmail.comwrote: Reposting here from the forums: Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release Candidate 1 out, with a much-improved GUI. Bad news: all the translations for the old wxWidgets Bitcoin are obsolete, and the process for making translations is different. Is anybody willing to write new translations? Here's what you'll need to know: Three translations already exist: de nl and ru. Translations are stored in .ts files in the src/qt/locale folder The 'QT Linguist' tool can be used to create translations ... or maybe an online tool like Transifex could/should be used to crowd-source the work And is anybody willing to take the job of coordinating translation efforts, figuring out if Transifex is a good tool to use, and writing some documentation to make it easy for people to create and submit new translations? References: https://github.com/bitcoin/bitcoin/blob/master/src/qt/locale http://doc.qt.nokia.com/latest/linguist-manual.html http://www.transifex.net/ -- -- Gavin Andresen -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alert System
Resending to mailing list as I replied directly... On Thu, Sep 8, 2011 at 11:03 PM, Christian Decker decker.christ...@gmail.com wrote: Will w...@phase.net wrote: In fact, I think the alert system should relay (note, NOT display) messages *regardless of the key used*, so it isn't yet another our client gets special status thing, and can be used for other clients as well. Be careful though, if you relay everything, it suddenly *does* have DDoS potential... no more than other messages such as transactions. Only verified and valid trandactions are forwarded which is desired as it costs the sender a fee if he attempts to spam, messages have no such penalty. Maybe require a proof-of-work then? kind of defeats the purpose of the alert if it takes a long time to issue one. I think leave the alert in, but relay alert messages even if they don't use the correct key. This means that if we later decide to add new keys to the alert root trust then older clients will still relay these. my .02btc Will I'm for keeping it in there as well, maybe even extend it with a mechanism to sign other certificates giving alternative client developers the ability to issue their own alerts. Think ssl certificates... Regards, Chris -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model. http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
