Re: [Bitcoin-development] Deprecating midstate in getwork?
On Mon, Sep 26, 2011 at 3:42 PM, Nils Schneider n...@nilsschneider.net wrote: I'd like to simplify the internal reference miner and remove all dependencies on cryptopp (it's the only place we use cryptopp instead of OpenSSL). Unfortunately, cryptopp is also used to calculate getwork midstate. This field is redundant and the miner could easily calculate it from the blockheader so I'd like to remove it. Any thoughts? Where should such a change should be announced so all miners can be upgraded? I think one of the pools was already working on something like that? I'm pretty sure it can be removed, and I'm pretty sure somebody has already field-tested that guess. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
On Sat, Dec 17, 2011 at 7:44 PM, Jordan Mack jordanm...@parhelic.com wrote: While using DHT for storage of the block chain is an intriguing concept, I do not see how it is feasible. As Gavin noted, DHT is a system that is difficult to impossible to guarantee against data loss or manipulation. Even if we found a way to store the block chain in DHT, how would transactions be verified? As Gavin noted, you could ask the network, but cannot necessarily trust the peers you are connected to. Verification of the full block chain allows the client to trust no one. Well, the block chain data itself is internally self-validating. As long as you know the latest block's hash -- a big if -- there is no problem downloading all other block chain data from DHT or any other untrusted source. In a malicious case, you would notice latest-hash differs from non-malicious and wind up downloading multiple chains, when walking hashes backwards through a DHT/lookup table. So, a bit more work but nothing fundamentally less secure _on a trust basis_. Of course, I was focusing on data validation, which ignores other factors such as DoS'ing the DHT. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Network version increase
On Mon, Apr 2, 2012 at 11:23 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Any opinions about a numbering scheme? Currently the value 6 is used. We could simply start increasing the number one by one now for every change, or we could do a cleanup to 10 first, and start incrementing from there. It would be nice to have 10 as the baseline, frozen protocol. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 31
On Wed, Apr 11, 2012 at 11:42 AM, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 11, 2012 11:32:18 AM Mike Hearn wrote: Jeff asked for a BIP for the pong message, so here it is: https://en.bitcoin.it/wiki/BIP_0031 I thought we were going with 60001 for the protocol version bump? See pull #1081, which makes a few minor revisions along these lines. Mike's original pull still has my ACK, FWIW, too. Can pull either. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding request/reply id in messages
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote: Hi, I would like to discuss the following bitcoin protocol improvement proposal: Adding request/reply id in all messages (in the message header, based on what was done for the checksum field) The original reason is that I found it very hard to implement robust blockchain downloading as we are missing context information: The download protocol relies on the other peer sending one (or more) inv reponse(s) to getblocks and sending the hashContinue. But if the other peer doesn't send a response to getblock, send a partial response to getblocks, mixes it with some unrelated blocks inventories or doesn't send the hashContinue it is very hard to detect and handle (e.g. ban the peer and switch to another). This could cause some DoS attacks by misbehaving peers. If the peer is misbehaving, then disconnect. Your protocol change does not offer any clear benefits in this area, as these sorts of attacks/misbehaviors/bugs are still just as possible, and just as damaging (or not). Just disconnect the strange peer! The problems are that 1/ we don't know how many inv messages to wait for after getblocks and 2/ we don't know how to distinguish between result of getblocks and spontaneous inv notifications. The same is true for addr messages (it is both a notification and reply) but this is less of a problem as a lack of response to getaddr doesn't constitute a DoS. The idea would be to add a new requestid field in messages and define the following: Stateless protocols have a lot of value. They are easiest to implement, and easier to prove correct. Existing clients like ArtForz' half-a-node, variants of which are deployed all over the place in bitcoin-land, rely on the stateless-ness to one degree or another. Stateful protocols, too, have their problems as well. One must add code to help remain synchronized between local and remote states, which your suggested change only hints at. NFSv4 and RPC have a long history of dealing with stateful-ness issues. Obviously bitcoin P2P is nowhere near as complex, but the history of NFS development offers several lessons applicable to your proposed change. Overall, IMO your listed reasons for needing this major change (stateless-stateful) do not really justify the change. Handling initial block download can be accomplished in a number of ways, and peer(s) may crash or return odd results. You must handle these cases properly, regardless of the presence of req/reply id's. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
Not sure whether this rises to the level of a BIP or not, as it is largely an implementation change. One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Although this only impacts a small amount of TX's ultimately, what it does do is give us the ability -- once miners have upgraded to this rule -- to tell bitcoin users that their transactions expire after N days. Backwards compatibility should not be an issue; clients are free to retransmit their TX at any time, as usual, thereby resetting the clock for all peers who have forgotten the TX in question. Once in place, clients may then implement code that notices a TX has expired (read: likely to have been forgotten by the network, assuming they themselves have stopped retransmitting it). Then you can start working on wallet/coin recovery, perhaps resending with a higher fee etc. The above change is not really fill-or-kill but it should be a big step, opening the door to deterministic TX behavior. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner etothe...@gmail.com wrote: My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. Do you have a -specific- concern that you feel may be exploited? Expiration already occurs at random, as nodes shut down and restart, log on and log off the network. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn m...@plan99.net wrote:
It sounds OK as long as you exclude nLockTimed transactions.
ACK, agreed
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers immediately. Today it's painful because the protocol isn't very
chatty - in bitcoinj I plan to do this by announcing to half the
connected peers and waiting to see if the transaction comes back on
the other half. Getting a response from a peer that the TX was dropped
for reasons {x,y,z} is a better design but needs another protocol
change.
So having transactions expire would address the case where somebody
broadcasts a transaction that successfully propagates across the
network, but then isn't actually accepted by miners for some reason.
Correct. As mentioned, this change should impact few TXs on the
existing network.
It's mostly about getting everyone to collectively agree that
transactions should expire, if they don't make it into a block.
(excl. nLockTime stuff) A minor technical step, but also a useful
policy step.
For instance due to a change in the default fee schedules. That risk
can be mitigated somewhat by being careful about such changes (timed
phase ins set multiple months out so people have time to upgrade,
alerts announcing it, etc).
I'm not sure we should be encouraging users to attach fees to
transactions though. Even if you can replace a transaction after a
couple of days, the user experience of trying to get the fee right
is atrocious.
Yes -- I think there is near-universal agreement on this user experience point.
I don't think any sensible merchant will actually be
willing to put their customers through this nonsense. If somebody
broadcasts a transaction that successfully propagates across a big
chunk of the network but then gets stuck due to lacking sufficient
fees, the best fix is for the merchant to broadcast another
transaction that spends the first and increases the fees on it that
way. After this happens a few times, if I was a merchant I'd be
tempted to just ask buyers to submit the TX to me directly and I'll
handle keeping up with what miners currently charge and attaching
fees. I don't want my customers to have to think about this and have
trades spuriously fail when they forget.
That design requires a minor change to how fees are calculated inside
the memory pool, to include fees on un-included dependencies. But that
seems fairly uncontroversial to me. It's best for users, merchants and
miners to not leave chains of transactions in limbo when together
their fees add up to the minimum required amount.
So, to be specific... a A-B chain of transactions, that collectively
meet the network's fee requirements? It seems quite reasonable to
accept that, sure. ACK on concept. A chain of length 2 seems like it
would be most common, and limiting total chain length (to 10? 100?)
for any one chain in the memory pool seems prudent.
As to the larger issue of fees... I will readily admit I have no good ideas.
The user's experience is pretty poor: while it might make economic
sense, from the network's standpoint, to charge for the service of
verifying and storing a transaction, the user has limited means to
determine an ideal fee. There are also other valid economic models
(receiver pays fee) out there that may successfully sustain the
network.
Ideally the fee, if any, is market based and negotiated. The current
method is loose-consensus, mainly aimed at (a) combating dust spam or
(b) ensuring it becomes increasingly more expensive to fill a block,
up to the current 1MB maximum. I think almost everyone agrees the
current fee system is an ugly, warty hack. Problem is... like
democracy, no matter how ugly it is, people have trouble finding a
better system :)
Furthermore, many of these ideas -- like sending TX's directly to the
merchant -- involve far more direct payee-payer communication on the
part of the wallet client than is currently envisioned by the bitcoin
P2P network design, which is broadcast-oriented. So, it remains an
open question whether we want the base bitcoin layer to even worry
about real-time fee negotiation and direct TX transmission.
It is possible that an instant-payments layer evolves on top of the
base bitcoin block chain layer, with bitcoin transactions evolving
largely into settlements between instant-payment intermediaries large
and small.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn m...@plan99.net wrote: So, to be specific... a A-B chain of transactions, that collectively meet the network's fee requirements? Yes. ACK on the concept Ideally the fee, if any, is market based and negotiated. Problem is... like democracy, no matter how ugly it is, people have trouble finding a better system :) I think this is something we can explore over the coming years. I favor having people commonly pass transactions around outside the broadcast network with the transactions and their dependencies being broadcast only when there's a lack of trust between recipient and sender. The block chain is an optional service after all. Agreed. A TX is just a signed message. No reason why it -must- use mainnet's distributed notary service. Furthermore, many of these ideas -- like sending TX's directly to the merchant -- involve far more direct payee-payer communication on the part of the wallet client than is currently envisioned Yes, though it's worth remembering that the original Bitcoin design did have participants communicate directly. When I talked with Satoshi in 2009 he saw the pay-to-IP-address mode imagined as the normal way to make payments, with pay-to-address being used as a kind of backup for when the recipient was offline. In the end that's not how things evolved, but it the pendulum could easily swing back the other way. IIRC pay-to-IP was removed because it was unreliable -and- detrimental to privacy? ISTR Satoshi specifically disliking the privacy elements of p2ip. But I also have a gut feeling that these sorts of payments and direct communication should be done via a wholly separate protocol than the bitcoin P2P protocol. Doing p2ip as it was done originally, inside the bitcoin P2P protocol, was a mistake. Extensible as it is, I think a better job -- and faster evolution -- can be done with a separate protocol on a separate port. Some HTTP derivative would probably make life easier for mobile payments and firewalled scenarios, and for client-merchant communications, for instance. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: Some HTTP derivative would probably make life easier for mobile payments and firewalled scenarios, and for client-merchant communications, for instance. Have you ever read https://gist.github.com/1237788 ? Looks like you're already headed in the right direction :) -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote: Try Reply to All That puts the sender in 'to' and list in 'cc', which dupes to the sender and eventually blows out the to and cc lines as everyone chimes in and doesn't trim. 'reply to' solves most of that. assuming the list sw can do it. Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 Personally, all this seems far too focused on a centralized website (bitcoin.org), and presents far too many choices at once to the user. On bitcoin.org (registered by Satoshi), I would rather see the Satoshi reference client and perhaps an other clients link on the wiki. Modern websites are working hard to _reduce_ the number of download links, not _increase_ them. See, e.g. http://fedoraproject.org/en/get-fedora where a single download choice is presented, and then an other options link is below the great big download button. Rather than fighting over what a particular bitcoin.org page should look like, why not maintain an independently managed BitcoinClients.org website? Or GetBitcoinClient.org or somesuch. Solve this problem in a distributed fashion, rather than stuffing it all onto bitcoin.org. Bitcoin.org, IMO, is the home of the reference project not the entire bitcoin community. Emphasizing that months ago was why the forum was moved to bitcointalk.org. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
On Wed, May 16, 2012 at 12:34 PM, Amir Taaki zgen...@yahoo.com wrote: Please check out my proposal, https://en.bitcoin.it/wiki/BIP_0033 I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way. I do not object to the concept, but the discovery process should be improved. Even venerable SMTP has a better, more flexible capabilities discovery process. Instead of further overloading service bits in the version message, or altering the version message, let us instead make feature discovery an easy, flexible, extensible process. We can add new commands without impacting older nodes, so let's create a new command get-features (or pick your name) that returns a list of key/value pairs. The key is a string, the value type is determined by the key. Standard behavior of clients would be to send get-features after seeing remote version info, as part of the initial connection handshake. In any case, the basic point is to move FAR away from fighting over a limited, inflexible resource (service bits in version msg) to something string-based and easily extensible. I can create this as BIP 34, if people wish. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)
On Wed, May 16, 2012 at 2:29 PM, Luke-Jr l...@dashjr.org wrote: That assumes you already have a connection to the peer in question. As I understand it, the service bits are propagated as part of the address, so you can see at a glance which nodes you want to connect to for some special service. Passing a huge list along might be unwieldy (though it makes sense for protocol changes that don't add new services). If the peer list becomes too, um, stratified maybe that's a Big Hint that said clients should be using another network entirely, and not overloading bitcoin's P2P network for wholly unrelated tasks. The bitcoin P2P network is not a general message transit network. Another argument against the proposal, IOW, if you ask me -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Punishing empty blocks?
There appears to be some non-trivial mining power devoted to mining empty blocks. Even with satoshi's key observation -- hash a fixed 80-byte header, not the entire block -- some miners still find it easier to mine empty blocks, rather than watch the network for new transactions. Therefore I was wondering what people thought about a client implementation change: - Do not store or relay empty blocks, if time since last block X (where X = 60 minutes, perhaps) or even stronger, - Ensure latest block includes at least X percent of mempool unconfirmed TXs The former is easier to implement, though there is the danger that no-TX miners simply include a statically generated transaction or two. The latter might be considered problematic, as it might refuse to relay quickly found blocks. Comments? It wouldn't be a problem if these no-TX blocks were not already getting frequent (1 in 20). -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
On Thu, May 24, 2012 at 1:13 PM, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote: optimization that avoids rechecking transactions that have already been verified as valid. Any transactions it doesn't have to verify are from the pool, of course :) Work in this area is already progressing, though it is outside the scope of this proposal regarding lazy miners and empty blocks. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
On Thu, May 24, 2012 at 1:27 PM, Robert McKay rob...@mckay.com wrote: If miners wanted to continue mining empty blocks without bothering to monitor the Tx pool they would just switch to stuffing the empty blocks with a dummy transaction of their own to get round your new rules. Yes. This was stated in the original email. Once the block reward halves in a few months time then receiving transaction fees will probably become more important to the miner's profit and loss calculations and they'll spend the extra time to implement proper transaction processing. I suspect if we do nothing this particular issue will go away. Perhaps it could be helped along by publishing some example code to make it easier for them. At current rates it is potentially years before that point is reached -- years of degraded service for existing users. The ability to refuse transactions seems like an important part of the game theory of transaction pricing. Miners are supposed to be able to jack up transaction costs by declining to process no fee or too low fee (in their opinion) transactions.. the counter balance is that they are losing money by doing that and leaving more on the table for the next miner to score a block. I expect that in the future there will be other instances when people complain that the miners are being 'unfair' and that the rules should be changed in some way to lower transaction fees (ie: increase block size). If you see a rule change, you have misunderstood the proposal. This is an -implementation- change, which users and miners are free to accept or reject as part of their choice of software to use in the bitcoin ecosystem. As such, miners continue to be free to build upon empty blocks, and let those blocks become part of a useful chain. You would not simply /ban/ empty blocks completely, but avoid relaying top-of-chain empty blocks. Mining power and network collaborate to choose the best chain at that point -- perhaps even including those empty blocks. Clients will continue to follow the longest, strongest chain, even after this implementation change. An implementation change is a soft vote of choice by the user, not a hard requirement on all users. I think it should be legitimate not to publish a transaction to the p2p network at all.. in the future there will probably be lots of networks other than the p2p network.. right now we have the IPv6 network and the IPv4 network.. in the future there could be many other protocols and perhaps not all transactions will make it back to the old legacy ipv4 p2p network or into the mempool of bitcoin nodes on that network.. but they should still be able to get into the block chain. See above -- such behavior is perfectly fine. It should be noted that out of band (OOB) TXs, transited through third party means outside P2P network, would not cause _empty_ blocks, as the block chain will continue to have traffic for the foreseeable future. OOB TXs are a great idea, too. In a hyperscaled bitcoin future, OOB TXs might even be the norm. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
On Thu, May 24, 2012 at 4:31 PM, Luke-Jr l...@dashjr.org wrote: These are problematic for legitimate miners: 1) The freedom to reject transactions based on fees or spam filters, is severely restricted. As mentioned in other replies, this is an important point of Bitcoin's design. 1b) This punishes miners with superior transaction spam filtering. As with all spam filtering, it is often an arms race and therefore the filter rules must be kept private by the miners, and therefore cannot be disclosed for the validating clients to take into consideration. This is simply not true given current available data, i.e. the current blockchain and ongoing not-spam transaction rate/pool. The argument that these are not rule changes is flawed: 1) As of right now, 99% of the network runs a single client. Anything this client rejects does de facto become a rule change. According to your own numbers even, this is not true. 99% of the network runs a wide variety of rules and versions. Even with a critical security announcement, the percentage of those running the latest version is not large. 2) Even if there were a diverse ecosystem of clients in place, discouragement rules that potentially affect legitimate miners significantly mess with the odds of finding a block. 3) If legitimate miners do not adopt counter-rules to bypass these new restrictions, the illegitimate miners are left with an even larger percentage of blocks found. Miners are not the -only- ones that get a say in what is spam, and what is not. If miners are generating garbage, network users have the right to veto that garbage. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
On Thu, May 24, 2012 at 8:45 PM, Luke-Jr l...@dashjr.org wrote: On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote: Comments? It wouldn't be a problem if these no-TX blocks were not already getting frequent (1 in 20). FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in 10) of 1-txn blocks is not actually unreasonable. This also means these 1-txn mined blocks are not necessarily harming Bitcoin intentionally. Anyone care to figure out the math for how fast miners need to finish processing transactions to reduce the number of 1txn blocks? Look at the time since last block, and correlate with the number of non-spam TX's in the memory pool at the time. It is obvious which ones are quick blocks (60 seconds since last block, no big deal) and which ones are the lazy miners ( 120 seconds since last block). -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Fri, Jun 15, 2012 at 9:43 AM, Mike Hearn m...@plan99.net wrote: How about see this project as a three part change? First step - add the mempool command and make nodes sync up their mempools on startup. Here's the mempool implementation: https://github.com/bitcoin/bitcoin/pull/1470 SPV nodes would definitely want to sync up their mempool upon startup. As for full nodes... I like the organic growth and random nature of the mempools. On the fence, WRT full node mempool sync at startup. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] SatoshiDice and Near-term scalability
On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas m...@justmoon.de wrote: The artificial limits like the block size limit are essentially putting [...] Changing the block size is an item for the hard-fork list. The chance of the block size limit changing in the short term seems rather low... it is a nuclear option. Hard-fork requires a very high level of community buy-in, because it shuts out older clients who will simply refuse to consider 1MB blocks valid. Anything approaching that level of change would need some good, hard data indicating that SatoshiDice was shutting out the majority of other traffic. Does anyone measure mainnet normal tx confirmation times on a regular basis? Any other hard data? Clearly SatoshiDice is a heavy user of the network, but there is a vast difference between a good stress test and a network flood that is shutting out non-SD users. Can someone please help quantify the situation? kthanks :) -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
Outside of major features advertised network-wide in nService bits, P2P protocol lacks a good method of enumerating minor features or extensions. The version number increment is coarse-grained, and is not self-documenting. A simple extension which lists supported commands is added, as demonstrated in this pull request: https://github.com/bitcoin/bitcoin/pull/1471 Another option is for verack to return this information at login, eliminating the need for a separate command/response. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell gmaxw...@gmail.com wrote: If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Agreed, and this would be why I support revert -- pull requests are for anything non-trivial. This practice of pull requests clearly should be followed in the case of controversial changes. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing it. Agreed. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin script opcode counts
On Thu, Jul 26, 2012 at 1:50 AM, Jeff Garzik jgar...@exmulti.com wrote: Just run a query over the entire blockchain, looking at script opcode use. I counted the number of times each opcode was used, in total: https://gist.github.com/3180470 And here is the testnet3 data: https://gist.github.com/3180486 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin script opcode counts
Just run a query over the entire blockchain, looking at script opcode use. I counted the number of times each opcode was used, in total: https://gist.github.com/3180470 (data in full) OP_0 104 OP_1 27 OP_2 12 OP_2OVER 182 OP_2SWAP 182 OP_3 16 OP_4 1 OP_CHECKMULTISIG 22 OP_CHECKSIG 12188693 OP_CODESEPARATOR 14 OP_DEPTH 182 OP_DROP 19 OP_DUP 1161 OP_EQUAL 88 OP_EQUALVERIFY 11699985 OP_HASH160 11700067 OP_IF 182 OP_IFDUP 182 OP_MIN 4 OP_NOP1 1 OP_NOP2 15 OP_NOP 5 OP_PUSHDATA1 18 OP_PUSHDATA2 4 OP_PUSHDATA 32350369 OP_SHA256 2 OP_VERIFY 182 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
On Sun, Jul 29, 2012 at 1:35 PM, Stefan Thomas m...@justmoon.de wrote: Big props to Gavin for adding those data-driven test cases. I can't overstate how useful they are. +1 they are a useful, cross-platform test tool. pynode will be making use of them shortly. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Version 0.7 release planning
There seems to be consensus that we should go ahead and do a release,
before leveldb or ultraprune or anything major lands. There is no
major landmark feature, but just a useful collection of small changes.
It seems like a good time to Release Early, Release Often and make a
checkpoint release.
Some rough draft release notes were dumped in
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.txt
Opening the floor... What do we collectively want to happen, before
0.7 release? What is the todo list for 0.7?
After cleaning out some pull requests yesterday, and looking at the
list today, I see
1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
luke-jr https://github.com/bitcoin/bitcoin/pull/1647
2) Translations update 2012-08-01 (fetched from Transifex)
Diapolo https://github.com/bitcoin/bitcoin/pull/1644
3) Add address groupings RPC from coderrr's coincontrol patches.
gmaxwell https://github.com/bitcoin/bitcoin/pull/1642
4) Add 'mempool' P2P command, and extend 'getdata' behavior
jgarzik https://github.com/bitcoin/bitcoin/pull/1641
5) PROBABLY NOT, BUT MAYBE: Relay blocks as a preview before
checking the transactions in them
luke-jr https://github.com/bitcoin/bitcoin/pull/1586
6) JSON-RPC method: prioritisetransaction txid priority delta
luke-jr https://github.com/bitcoin/bitcoin/pull/1583
7) HOPEFULLY: Addnode optimization and addnode access via RPC
BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
8) MAYBE: Transition to requiring block height in block coinbases
gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
9) WE MUST PICK ONE: RPC: lock push-down, preparing for
parallelization opportunities
jgarzik https://github.com/bitcoin/bitcoin/pull/1494
or
RPC: add facility to enable RPCs to run outside cs_main, wallet locks
jgarzik https://github.com/bitcoin/bitcoin/pull/1493
10) I THINK WE WANT THIS? Make IPv6 support optional again (defaults
to enabled)
luke-jr https://github.com/bitcoin/bitcoin/pull/1431
11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
luke-jr https://github.com/bitcoin/bitcoin/pull/936
Devs -- feel free to commit directly to doc/release-notes.txt if there
is a missing commit, or something that may be better described.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.7 release planning
On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik jgar...@exmulti.com wrote: There seems to be consensus that we should go ahead and do a release, before leveldb or ultraprune or anything major lands. There is no major landmark feature, but just a useful collection of small changes. It seems like a good time to Release Early, Release Often and make a checkpoint release. Procedural note: since Gavin is on vacation, this release obviously won't occur for at least a couple weeks. If Gavin appears on email or IRC, though, I might try to pounce on him and convince him to let us go ahead with 0.7-rc1, if the other devs are happy. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Custom Services
On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas m...@justmoon.de wrote: I was working on some custom protocol extensions for Bitcoin that I wanted to experiment with and I noticed that in order to enable nodes to announce these services the only mechanism the protocol currently provides is to use one of the 64 bits of the services field. This is obviously a resource that will run out quickly if we all just help ourselves, so I set out to come up with a standardized way to announce custom protocol extensions, without using up NODE_* flags. Please kindly review my solution: https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Services heh, this is not a new idea. I even implemented a pull request for service discovery myself, which simply consisted of querying the list of supported commands: https://github.com/bitcoin/bitcoin/pull/1471 On IRC, I proposed several alternatives including modifying 'version' (which you did) and a new getcaps (get capabilities) command to be added in protocol_version X. gmaxwell seems continually unenthused, and made a valid point about service advertisement: these capabilities are not advertised with CAddress, so how does one usefully discover and make use of them? What are real world use cases, that cannot be solved with nService bits? My only response is a weak one: inevitability. It seems likely that -somebody- will implement their own P2P commands for their own client subset, even if only a simple use 'getstatus' with strSubVer matching /FooClient/ Therefore, if it is inevitable, we might as well make some basic rules about how to extended your P2P command set. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Protocol changes for SPV clients: mempool, getdata commands
A small change to the protocol is proposed for satoshi client v0.7 (upcoming release): Add 'mempool' P2P command, and extend 'getdata' behavior https://github.com/bitcoin/bitcoin/pull/1641 The genesis of this command is to permit SPV clients to access the memory pool, but secondary uses include diagnostics and miner download (so that miners won't miss lucrative TX's due to node restart). getdata behavior is extended to include any memory pool transaction, relaxing a previous getdata restriction. Didn't feel this warranted a BIP, but can write one if people really want one. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 35: add mempool message
Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 Abstract --- Make a network node's transaction memory pool accessible via a new mempool message. Extend the existing getdata message behavior to permit accessing the transaction memory pool. Motivation --- Several use cases make it desireable to expore a network node's transaction memory pool: * SPV clients, wishing to obtain zero-confirmation transactions sent or received. * Miners, downloading existing network transactions after a restart. * Remote network diagnostics. Specification --- 1) Upon receipt of a mempool message, the node will respond with an inv message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An inv message is always returned, even if empty. 2) The typical node behavior in response to an inv is getdata. However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support mempool, an implementation must extend its getdata message support to querying the memory pool. 3) Feature discovery is enabled by checking two version message attributes: a) Protocol version = 60002 b) NODE_NETWORK bit set in nServices Backwards compatibility --- Older clients remain 100% compatible and interoperable after this change. Implementation --- See https://github.com/bitcoin/bitcoin/pull/1641 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
On Thu, Aug 16, 2012 at 1:40 PM, Amir Taaki zgen...@yahoo.com wrote: The format for mempool packet is missing. I'm guessing that it is an empty message, right? Yes, it is an empty message. BIP updated. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. Yes. An inv message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? A simple guarantee of 1:1 correspondence between request and response. The bitcoin protocol sometimes simply elides a response when the response would be empty, and this makes it difficult to know whether a request is timing out or already processed. Sending a ping(nonce) after each P2P command is another way of achieving same :) This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? I would like to suggest to allocate an extra service bit for this. We still have 63 left, and this is a well-defined and useful extra service that was not yet provided by any earlier node. Doing that would also mean that mempool-providing survices may be discovered before connecting to them, as the service bits are carried around in addr messages. Any opinions about that? An nServices bit would be a better fit for this optional service, but nServices bits seemed like a scarce resource, so I elected to be conservative. Absent the scarce-resource concern, I'd vote for an nServices bit. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
On MSG_MEMTX: The current version has a much higher Just Works value. On empty inv: It is generally better to do something unconditionally, than have a response generated only under certain conditions. And Alan is correct to note that unknown messages are ignored (intentionally, for expansion). However, unconditionally returning a response has little to do with feature probing/discovery. It is simply a clear, deterministic indication that processing is complete, for each invocation. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote: On MSG_MEMTX: The current version has a much higher Just Works value. On empty inv: It is generally better to do something unconditionally, than have a response generated only under certain conditions. And Alan is correct to note that unknown messages are ignored (intentionally, for expansion). However, unconditionally returning a response has little to do with feature probing/discovery. It is simply a clear, deterministic indication that processing is complete, for each invocation. I disagree. Returning an empty inv is a very strange way of replying empty mempool. Bitcoin P2P is not a request-response protocol, and inv messages are sent where there are inventory items to send. The reaction to a request (for example getblocks) can be nothing, or one or more inv messages if necessary. Special casing an empty inv to mean empty mempool is trying to hack a request-response system on top of the asynchronous system. OK, just updated 'mempool' branch to not return inv if mempool is empty. If there is need for confirming the transmission of the mempool is complete, the proposal to use a MSG_MEMTX sounds good to me. No client will ever receive such an inv without requesting the mempool, and implementing handling MSG_MEMTX is trivial. MSG_MEMTX is not a good idea for this use case. Just sent a ping(nonce). Bitcoin P2P processes requests in-order, and responds accordingly. The remote end may insert asynchronous messages into the response stream, certainly, but responses to queries are processed and returned in-order. A 'getdata' response is fully sent before a 'ping' response is sent, etc. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Atomic coin swapping?
Forum URL: https://bitcointalk.org/index.php?topic=112007.0 gmaxwell was talking about colored coins[1] in IRC recently. They are potentially interesting in the context of distributed bonds[2], which I am currently pursuing with pybond[3]. Here is the problem I am trying to solve, does the crowd have an answer? 1. Alice transfers a 1-satoshi colored coin to Bob. 2. Bob transfers 100 BTC to Alice. May be restricted to 1 txout, if that eases implementation details. 3. Steps #1 and #2 happen as an atomic unit, all-or-none. 4. Alice and Bob must both approve this atomic transfer of coins, with appropriate signatures. Is this possible within the current bitcoin system? As far as I can see, the answer is no but maybe I'm missing something. My best guess to the answer is possible, but requires a new SIGHASH_* type? [1] https://bitcointalk.org/index.php?topic=106449.0 [2] https://bitcointalk.org/index.php?topic=92421.0 [3] https://github.com/jgarzik/pybond -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Atomic coin swapping?
On Sat, Sep 22, 2012 at 5:10 AM, Jorge Timón timon.elvi...@gmail.com wrote: I'm very interested in this. I was expecting transitive/multi-hop transactions (Ripple) with colored coins, and I don't understand why is not possible. From https://en.bitcoin.it/wiki/Contracts --- SIGHASH_ALL: This is the default. It indicates that everything about Yes, SIGHASH_ALL was the crucial piece I was missing. I have updated the post to add a concrete example with as much detail as necessary for programmers to recreate. Review requested: https://bitcointalk.org/index.php?topic=112007.msg1212356#msg1212356 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large backlog of transactions building up?
On Sun, Sep 23, 2012 at 8:12 AM, Mike Hearn m...@plan99.net wrote: Has anyone got long term longs that contain the pool size and timestamps? Unfortunately I forgot to enable timestamps in the logs for my own nodes (the privacy benefit of disabling this by default is questionable, imho). But just looking at the general trends and cross-checking against my own memory it definitely seems that there are more and more pending transactions that don't get cleared into blocks. One of my nodes now routinely has 4000 transactions in the mempool. Blocks typically clear only a few hundred at most, which is what you'd expect given current transaction rates (around 300 per ten minute interval). So what are the other pending transactions doing and why aren't they getting drained out of the mempool? Yeah, my public nodes currently have 2200+ Over time, it gets cluttered naturally due to the disconnect between what miners mine and what relayers relay. I've long argued that all mempool implementations should limit the lifetime of any TX to a specific number of blocks. Rationale: - bitcoin clients retransmit until TX is confirmed - provides a deterministic lifetime for a TX; if you KNOW a TX will disappear 144 blocks (24 hours) after you stop transmitting, then it is probably safe to initiate recovery procedures and perhaps revise the transaction - prevents zombie TXs from littering memory... they hang around, wasting resources, but never get confirmed No one has strenuously argued against this, so I suppose it is down to writing a patch, and coming up with a good number we (as a network) can agree upon. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
On Wed, Sep 26, 2012 at 12:06 PM, Mark Friedenbach m...@monetize.io wrote: Certainly developers should be responsible for making sure that regression tests for bugs they fix make it either into the unit tests or Matt's functional test repository. QA should hold them accountable for that (re-opening tickets for bugs that have been fixed but without regression tests). As a goal or general principle, this is agreeable. But slavish attention to this will only get ignored. There is finite developer resources, and regression tests for certain types of bugs, like prickly P2P network interaction bugs or RPC API bugs, could potentially involve many days or weeks of coding, to sufficiently simulate the environment. The ability to easily, automatically and programmatically reproduce certain classes of bugs is simply out of reach right now, and nobody is going to shut down development to fix that problem. We should move towards this direction, yes, but bitcoin test cases are not always going to be as easy as writing (say) a compiler testcase. We can always use the help of a few good QA coders: simulating a P2P environment and checking the RPC API are two examples of very complicated problems that -can- be automated for testing... with a lot of work. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes pe...@coinlab.com wrote: This is small, but an interesting tidbit from BTC Foundation payments; roughly 3-5% of our initial members double-spent. WOW, that's terrible. To be specific, do you mean a) paid twice or b) sent BF coins, then sent the same coins elsewhere ? Double-spend is a specific technical term -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] performance testing for bitcoin
On Wed, Oct 3, 2012 at 1:38 PM, Ian Miers imie...@jhu.edu wrote: Whats the best way to get performance numbers for modifications to bitcoin ? Profiling it while running on testnet might work, but that would take a rather long time to get data. Is there anyway to speed this up if we only needed to provide relative performance between tests. (in a sense a fast performance regression test). You have to be specific about what you're measuring, because performance is vague. You can measure many aspects of blockchain performance by importing blocks via -loadblock=FILE. Other performance measurements like how fast does a block relay through the network cannot be as easily measured. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] 0.7.1 release
On Wed, Oct 3, 2012 at 1:49 PM, Gavin Andresen gavinandre...@gmail.com wrote: Add -reindex, to perform in-place reindexing of blockchain data files : https://github.com/bitcoin/bitcoin/pull/1870 Agree, though needs testing P2P: Do not request blocks from peers with fewer blocks than us : https://github.com/bitcoin/bitcoin/pull/1834 Agree Add new RPC lockunspent, to prevent spending of selected outputs : https://github.com/bitcoin/bitcoin/pull/1861 Agree, though sipa raised a valid issue. lockunspent, like the existing listunspent, is wallet based. As raw transactions might spend outputs _not_ in the wallet, lockunspent would miss those. I think this is OK, because listunspent is already wallet-based, but it should be noted. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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
[Bitcoin-development] On bitcoin testing
Copying from a response posted to Bitcoin software testing effort https://bitcointalk.org/index.php?topic=117487.0 as it is relevant to a recent thread here... Any level of testing is useful and appreciated. Various types of testing that are helpful: * it works testing: Simply run the latest Release Candidate (or latest version, if released). Make sure all the basics work (for whatever definition of basics you desire). This is the level most accessible to casual users. * Major features testing: Develop a short checklist of must-work features, and organize volunteers to work together and go through that checklist, item by item. Test each major feature on each major platform. * Stress and fuzz testing: Attempt to stress the system somehow, or randomly corrupt bits of data. See what breaks. * Regression testing: Record bugs fixed, and develop automated test cases that successfully reproduce the bugs on older versions, and verify newer versions remain fixed. * Unit function testing: Rigorously exercise each C++ class to ensure it behaves as expected at a micro level. * Full peer automated testing: Automated testing of RPC and P2P functions is non-existent, because of the difficulty in doing so. Find a solution to this problem. * Data-driven tests: If possible, write software-neutral, data-driven tests. This enables clients other than the reference one (Satoshi client) to be tested. Embed tests in testnet3 chain, if possible. The community at large can be a big help simply by doing the first item: download and run the Release Candidates and the latest version, and report any problems. Even reporting success is fine by me, for example: Version 0.7.1 works for me on Windows 7/32-bit posted on a forum thread. It is always very difficult to organize any sort of testing regime with open source volunteers that come and go. Each volunteer chooses their level of involvement. Any amount of testing and test-case writing, large or small, is helpful to bitcoin. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] 0.7.1 release candidate 1 ready for testing
On Thu, Oct 11, 2012 at 11:46 AM, Gavin Andresen gavinandre...@gmail.com wrote: Any progress on a release candidate QA sanity testing plan? Posted a call for testing in this forum thread, https://bitcointalk.org/index.php?topic=117487.0 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] 0.7.1 release candidate 1 ready for testing
On Thu, Oct 11, 2012 at 1:51 PM, Arklan Uth Oslin arklan.uthos...@gmail.com wrote: i'll second the bitcoin test list. As you like, but... bitcoin-devel is quite low traffic, so there is not exactly an issue of crowding. And a separate list means people cannot chime in as easily. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen gavinandre...@gmail.com wrote: This is the next big lets all agree to do things the same way thing I think we should tackle. I'm particularly looking for feedback from other bitcoin client developers, even if it is just a quick looks reasonable, if everybody else is going to do it then I will (eventually) too... Comments: 1) Payment message should include ability to specify the transaction _or_ a transaction id sent via normal means over the network. 2) I think a significant bitcoin userbase will want to operate outside the full root-CA chain. Just look at https:// websites now. Self-signed certs are quite common, because it is easier, while being more secure than http:// So some provision for self-signed certs, a use case in wide use elsewhere, or equivalent thereof, seems reasonable. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] RFC: Updating dust output definition, and default fees
URL: https://github.com/bitcoin/bitcoin/pull/2100 1) Create COIN_DUST constant, to represent the dust spam limit used. 2) Decrease COIN_DUST to 0.001 BTC Rationale: With the increase in bitcoin value (US$13.67 as of this writing), it seems reasonable to reduce the value level of which we consider dust spam. 3) Update TX miner and relay fee defaults to 0.001 / 0.0005 BTC respectively Rationale: Reflects growth of dust spam in unspent transaction output dataset. Review of impact: a) Definition of COIN_DUST reduced from 0.01 to 0.001. b) Miners who mine with this code will require a fee = 0.001 to include TX's with outputs = COIN_DUST c) Normal clients will require a fee = 0.0005 to relay TX's with outputs = COIN_DUST -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Thu, Jan 10, 2013 at 10:59 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: Ive been missing lately, when is 0.8 targeted for freeze? 0.8rc1 will probably happen when the core ultraprune/leveldb stuff is stable. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: make the private key for testnet genesis block public
On Mon, Jan 14, 2013 at 5:44 AM, Peter Todd p...@petertodd.org wrote: Basically on testnet we should give people the chance to test how their code handles attempts to spend the genesis block coinbase, as well as other tx's made to the genesis block address. After all, potentially Satoshi is still out there, still has that key, and still may cause exactly that situation himself. ACK -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Testnet DNS seed
On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd p...@petertodd.org wrote: Everything is running on a dedicated Amazon EC2 micro instance. Just IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels are broken. I also haven't setup tor yet. I can do both if there is demand. How long do you plan to run this? Indefinitely [presuming there is interest and users]? I guess the next step is to create a new strTestNetDNSSeed in the satoshi client, although it'd be better if at least one more person had No objection a testnet seed to include in the list. Probably best to leave IRC enabled too. Yes, IRC must remain enabled Also, FWIW, it looks like the pnSeed list is way out of date... Yes. Usually nanotube does the update when poked. That can happen, or something different. A nice alternative might be a simple script that transforms Pieter's seeds.txt into pnSeed[] -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Testnet DNS seed
On Sun, Jan 27, 2013 at 5:27 AM, Peter Todd p...@petertodd.org wrote:
On Fri, Jan 25, 2013 at 09:23:28PM -0500, Jeff Garzik wrote:
On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd p...@petertodd.org wrote:
Everything is running on a dedicated Amazon EC2 micro instance. Just
IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels
are broken. I also haven't setup tor yet. I can do both if there is
demand.
How long do you plan to run this? Indefinitely [presuming there is
interest and users]?
Indefinitely. It's a pretty cheap thing to run, about $7.5/month. If
anyone else wants I can give them a machine image copy easily too.
Cool. ACK on adding your seed to the ref client.
Also, FWIW, it looks like the pnSeed list is way out of date...
Yes. Usually nanotube does the update when poked. That can happen,
or something different.
A nice alternative might be a simple script that transforms Pieter's
seeds.txt into pnSeed[]
seed.txt? You mean the dumpfile produced by bitcoin-seeder? That has
Correct.
uptime info, although only a months worth if I understand it correctly.
pnSeed probably should be filtered with SORB's dynamic ip list or
similar too, and additionally add an expiry time. (1 year?)
That's fine. The main point was to create something scripted and
repeatable. Then pnSeed[] becomes easier to maintain _and_ easier to
audit. Right now it is a bit opaque with a list of hex constants. A
script or makefile rule could do
cd src
../contrib/gen-seeds.py seeds.h
and seeds might look like
#ifndef __SEEDS_AUTOGEN_H__ etc.
unsigned int pnSeed[] = {
0xABCD1234, /* IP addr 12.34.56.78 */
};
I think Satoshi liked them opaque and not easily searchable, so
printing the readable IP address in a comment may not be desired.
Anyway, that output would make updating the list more transparent and
easy to maintain.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension
On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: Introducing super-nodes with thousands of connected peers can greatly help here. UDP is connectionless. I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ It depends on the usage. Simply broadcasting a TX or INV to a remote peer does not require a connection, clearly... but you probably want to signal acceptance of those messages somehow. But other uses, like subscribing to a broadcast, does require some notion of an association. In the rough draft, a parallel TCP connection with version/verack sequence is required, and you may make use of it if a connection is needed. But that is just one approach. A more robust, heavyweight UDP P2P might be a hole-punching TCP alternative. It's up to the community and results of experimentation. Bittorrent has evolved a full transfer protocol over UDP, to get around firewalls and the like. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] Upcoming network event: block v2 lock-in
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind 0.7 or later? slush, BTC Guild, ozcoin too I think, several others. Not for producing coinbases (where BIP 34 is implemented). Sure, that is largely the pool server layer. But it is misleading to imply that bitcoind is nowhere in the stack. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] A bitcoin UDP P2P protocol extension
On Sat, Mar 23, 2013 at 9:22 PM, Gregory Maxwell gmaxw...@gmail.com wrote: In some ways SCTP is a pretty optimal transport for Bitcoin like messaging. Darn near everything can be shoehorned into a message So absolutely agreed... in theory. Been an SCTP fan for years. Firewall practices tend to put a damper on cool new protocols like that, though. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- 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] bitcoin pull requests
On Tue, Apr 2, 2013 at 11:41 PM, Wladimir laa...@gmail.com wrote: Maybe now that bitcoin is growing out of the toy phase it's an idea to start gpg signing commits, like the Linux kernel (https://lwn.net/Articles/466468/). But I suppose then we can't use github anymore to merge as-is and need manual steps? Correct, that rules out github, AFAICS. Though, honestly, when I ACK that means I read the code, which is more important than the author really. github seems fine for that still, though I do wonder if there is a race possible, * sneak uploads innocent branch sneak/bitcoin.git #innocent * sneak creates pull req * just before I click pull, sneak rebases the branch to something evil -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DOS-Attacks on bitcoin-client?
BTW, check out the blockchain torrent, as one way of offloading some of the download bandwidth used from the P2P network: Bitcoin blockchain data torrent https://bitcointalk.org/index.php?topic=145386.0 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] On-going data spam
http://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/ TD petertodd: yeah somebody put a file upload tool into the chain and then tried to upload the entire amibios source code to it. stupid. TD someone thinks it's a lot more important than it really is petertodd TD: and 2.5MB of wikileaks data, and a whole bunch of GPG encrypted stuff, and the hidden wiki cp/jb sections (no idea if it's all the same person) petertodd jgarzik: https://blockchain.info/address/3Dw3UB6VZ3a3ay5diDQVwUFXzKScJJLeVU iirc this is gpg symmetric key encrypted petertodd jgarzik: (I wrote a tool to download the tool to download data) petertodd MC1984_: just checked, surprisingly no-one has put *anything* into the litecoin chain at all, strings returns nothing -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
Well, I'm not fundamentally opposed to a blacklist, but it would have to be done in a VERY open manner. I do think the community would agree that storing big data transactions is not the primary purpose of bitcoin. However, there should be some metrics and heuristics that take care of this problem. Notably the dev consensus (sans you, Mike :)) seems to be that uneconomical outputs should be made non-standard. Here is one approach: Block uneconomic UTXO creation https://github.com/bitcoin/bitcoin/pull/2351 I would like to see at least a stopgap solution to data spam in 0.8.2, as it is a clear and present problem. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 9, 2013 at 10:53 AM, Mike Hearn m...@plan99.net wrote: However, there should be some metrics and heuristics that take care of this problem. Notably the dev consensus (sans you, Mike :)) seems to be that uneconomical outputs should be made non-standard. I think that patch is ok as it doesn't really have any fixed concept of what is uneconomical. But I haven't thought about it much. As Gavin says, there's an obvious backwards compatibility problem there. It should probably wait until the payment protocol work is done, so the major user of micropayments-as-messages can migrate off them. wait is only an option if there is an alternate solution already coded and ready for 0.8.2. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Fri, Apr 19, 2013 at 12:38 AM, John Dillon john.dillon...@googlemail.com wrote: I understand that Gavin has spent effort on security efforts against small-scale attackers. It's the fact that he is so dismissive of the threat that large attackers play that is what bothers me. But if I am being divisive I understand. I cannot speak for Gavin, but speaking more generally, large attackers tend to belong in a thought-class all their own. Example 1: if some super-ASIC miner arises with 90% of hash power, and he starts behaving in a way contrary to the useful functioning of bitcoin, the community might decide to change the PoW algorithm at block height N. Example 2: If someone large DDoS's the entire P2P network, which is possible, manual intervention would be required to straighten out the mess. In each case, it's more about the community's mutual defense actions than any prepared defense. Speaking even more generally, bitcoin may be a billion-dollar invention, but that doesn't mean it has any funding for network defense! Unless cost structures and user attitudes change, development and deployment of major defense strategies seems unlikely. Which implies the community will simply wait for a [attack | explosion | crisis], and then hope we can unwind/repair the damage afterwards. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge) rebroad+sourceforge@gmail.com wrote: As part of a roadmap for block downloading, I think this may be a good time to look into providing an HTTP/HTTPS protocol for block downloading - this would also allow web proxies to cache blocks and thus make it more accessible, as well as cater for resumeable downloads. Speaking generally, I've always been a supporter of finding new and creative ways to store and transmit blocks. The more diversity, the less likely bitcoin can be shut down worldwide. HTTP is fine, but you run into many issues with large files. You would need a very well defined HTTP-retrievable layout, with proper HTTP headers along the entire path, if you want web caches to function properly. You need HTTP byte range support, HTTP 1.1 keep-alives, and other features for resuming large, interrupted downloads. The format currently used by bitcoind would be just fine -- blocks/blk.dat for raw data, size-limited well below 1GB. Just need to add a small metadata download, and serve the raw block files. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
On Tue, Apr 30, 2013 at 3:27 PM, Andy Parkins andypark...@gmail.com wrote: On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote: The format currently used by bitcoind would be just fine -- blocks/blk.dat for raw data, size-limited well below 1GB. Just need to add a small metadata download, and serve the raw block files. That doesn't seem very generic. It's tied far too much to the current storage format of bitcoind. Hardly. The storage format is bitcoin protocol wire format, plus a tiny header. It is supported in multiple applications already, and is the most efficient storage format for bitcoin protocol blocks. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? You don't have to create anything on the fly, if you store blocks in their native P2P wire protocol format. http://bitcoind.example.com/block/BBB http://bitcoind.example.com/tx/ http://bitcoind.example.com/block/oftx/TTT http://bitcoind.example.com/peers http://bitcoind.example.com/peer/nnn Essentially: block explorer's raw mode but in every bitcoind. The hardest operation for light clients is finding out the block that contains a particular transaction -- something that bitcoind already knows. This is a whole new client interface. It's fun to dream this up, but it is far outside the scope of an efficient HTTP protocol that downloads blocks. Your proposal is closer to a full P2P rewrite over HTTP (or a proxy thereof). -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Hello all, I think it is time to move forward with pruning nodes, i.e. nodes that fully validate and relay blocks and transactions, but which do not keep (all) historic blocks around, and thus cannot be queried for these. The biggest roadblock is making sure new and old nodes that start up are able to find nodes to synchronize from. To help them find peers, I would like to propose adding two extra service bits to the P2P protocol: * NODE_VALIDATE: relay and validate blocks and transactions, but is only guaranteed to answer getdata requests for (recently) relayed blocks and transactions, and mempool transactions. * NODE_BLOCKS_2016: can be queried for the last 2016 blocks, but without guarantee for relaying/validating new blocks and transactions. * NODE_NETWORK (which existed before) will imply NODE_VALIDATE and guarantee availability of all historic blocks. In general, I support this, as anybody on IRC knows. Though it does seem to open the question about snapshotting. Personally, it seems important to enable running a fully validating node, that may bootstrap from a UTXO snapshot + all blocks since that snapshot. NODE_BLOCKS_2016, in particular, is too short. For users, I've seen plenty of use cases in the field where you start a network sync after a 2-week period. Set a regular interval for creating a UTXO snapshot, say 3 months (6*2016 blocks), and serve all blocks after that snapshot. For older nodes, they would contact an archive node or torrent for 3 month blocks, and then download normally = 3 month blocks (if the archive node didn't serve up to present day). Where are we on nailing down a stable, hash-able UTXO serialization? -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Sat, May 4, 2013 at 2:07 PM, John Dillon john.dillon...@googlemail.com wrote: After all Peter, just like you have implemented alternate block header distribution over twitter, in the future we should have many different means of peer discovery. Right now we have DNS seeds, a fixed list, and IRC discovery that does not work because the servers it was pointed too no longer exist. Not a good place to be. Let's not confuse bootstrapping with overall peer discovery. Peer exchange between P2P nodes is the primary and best method of obtaining free peers. Obviously you need to bootstrap into that, though. DNS seed and fixed list are those bootstrap methods (IRC code was deleted), but are only used to limp along until you can contact a real P2P node, at which point peer discovery truly begins. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Mon, May 13, 2013 at 5:12 PM, Adam Back a...@cypherspace.org wrote: When you said destroy-via-miner-fee: Don't forget: 4. destroy-via-miner-fee, which is useful because it provides funding for a public service (bitcoin transaction verification). Is that directly possible? Because the reward transaction has no source, and no fee? Or can you put a 25BTC fee in the reward transaction in the coinbase? When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, that might look like Input 1: 1.0 BTC Output 1: 0.5 BTC (the miner fee is implicitly 0.5 BTC, paid to whomever mines the transaction into a block) Sadly the bitcoin protocol prevents zero-output, give-it-all-to-the-miner transactions. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 5:25 AM, Adam Back a...@cypherspace.org wrote: On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote: When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, that might look like Input 1: 1.0 BTC Output 1: 0.5 BTC (the miner fee is implicitly 0.5 BTC, paid to whomever mines the transaction into a block) Sadly the bitcoin protocol prevents zero-output, give-it-all-to-the-miner transactions. Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. That evaluation largely depends on the needs of the service in question. In my decentralized identity (SIN) example, you merely need to prove to the cloud that you sacrificed some bitcoins to any-miner. The confirmed, in-chain, non-coinbase transaction becomes the root node for off-chain identity data. The penalty for the user withholding the sacrifice transaction is that their SIN is not created. That incentive may not exist in that way, in another service. Or do you mean to say you could have (implicit reward 25BTC) and reward transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and validation semantics? That would be close enough to give-to-miner. Also the output sum 0BTC limitation could be changed to = maybe... (just one well placed character :) Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: We would only end up with few copies of the historic data if users could choose what parts of the blockchain to store. Simply store chunks randomly, according to users available space, and give priority to the N most recent chunks to have more replicas in the network. You don't need bittorrent specifically for a DHT, if publicity is a problem. There are many DHT proposals and implementations, and i bet one of them should be more suitable to the bitcoin network than bittorrent's. That's just about the worst thing you could do for bitcoin. DoS one part of the DHT, you DoS the entire blockchain by breaking the chain. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach m...@monetize.io wrote:
So as to remain reasonably compliant with RFC 4122, I recommend that we
use Version 4 (random) UUIDs, with the random bits extracted from the
double-SHA256 hash of the genesis block of the chain. (For colored
coins, the colored coin definition transaction would be used instead,
but I will address that in a separate proposal and will say just one
thing about it: adopting this method for identifying chains/coins will
greatly assist in adopting the payment protocol to colored coins.)
This proposal seems closer to Version 5 than Version 4, in spirit.
But given that useful content may be deduced from UUID, it is not
truly applicable to either. A bitcoin-specific version 6, if you
will.
And some example chain identifiers:
mainnet: UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')
Note that, as this example unintentionally implies, humans are going
to want a side-by-side mapping /anyway/, just to make it readable and
usable to humans.
Almost all useful multi-chain software will require a readable
shortname string anyway, the thing this proposal wishes to avoid.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@gmail.com wrote: Some out of band algo/hash could work so long as there was a one to one relationship between the described object and the UUID. In this case the gensis block may not uniquely identify a coin. What does this mean? It seems extremely unlikely that two different genesis blocks will have the same hash. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@gmail.com wrote: Some out of band algo/hash could work so long as there was a one to one relationship between the described object and the UUID. In this case the gensis block may not uniquely identify a coin. What does this mean? It seems extremely unlikely that two different genesis blocks will have the same hash. Two coin ecosystems could have the same genesis block That has really, really bad side effects. The whole point of the bitcoin consensus algorithm is to avoid situations like this. We don't want to encourage that behavior with code. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wed, May 22, 2013 at 10:29 AM, Luke-Jr l...@dashjr.org wrote: In some cases, multiple currencies can use the same blockchain (not just the singular genesis block). This use case *is* something we want to encourage - no reason for people to make an entirely new blockchain if their altcoin fits within the scope of Bitcoin or another existing altchain. OK, let me qualify. Layers on top are one thing, but we really do not want to support cases like the fork that leaves the genesis block intact, and leaves the subsidy at 50.0 BTC forever. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Changing PGP identities/keys
As part of the process of moving to BitPay, I'll be switching to jgar...@bitpay.com as a PGP identity, with brand new signing keys. Here is a message, signed by jgar...@exmulti.com's key (the one listed on bitcoin.org), proving they are the same person. http://yyz.us/jgarzik-now-at-bitpay.txt http://yyz.us/jgarzik-bitpay-pubkey.txt If a couple people would run through this and verify that I am me, I would appreciate it. A sig check and IRC ack would be great. Thanks! bitcoin.org will be updated after this. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Garzik's business identity and PGP information is: pub 2048R/7ADCA079 2013-05-23 Jeff Garzik jgar...@bitpay.com Fingerprint=3710 4081 6275 9FC5 A429 6536 E7A5 8E33 7ADC A079 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUBUZ4ykNodwg8tvwyoAQImAg//WdYc4RpZDtLUGWGMXr4Jnme9gjLdmFr4 em1McXk7faHls/qbQOlKdi46mTm4E/RZ6SLE7wMQkPD5RD0ukx3zkkFznbAuBuw2 /wCmNP2Tt/PZI2x3e9gfdBL0WxVfDTczZtMEMhz0ovMm3MtfZ8Xv9GtK3go+4LXa eX4OguGVsuh/iJ1fSgr9ObZM1RSC7d7niXDw7oK8St6+G9z/4JiAs7jSpG1/jkw1 hNqSwxXSL/N5rbccPNvR91jWL7s63MQbrjYSWADxJQ81vLwV6JbyANyc6HnkfrPY s0LmqtGqO3qa3xikhde8Iw0urejgyLSSJXcYLak+3TgRZqXmqJWhCW5bwRmathht Y7Aev1g5oUsrX1KfvSwc76U13C8lqCzi2ICmUt1r2nMDR74hi8rxsxlY/axqZ2nJ v2wROiD1ecxBx6rWeSi6K6cl3Oa7jUMkAk0avlw8Ozg/cXDmWqDzqyrLVZNFlDni FeoAbgoJ6AnKULVyMLjwHQqx4Dg7tFGFiVefkiNMsXijwhXE2IxiEK52yvBN1M06 UWwmwBIqFnUnCHN98UGbI4yT9favE2eqKAChvQo4TowaycCw5wNtI1zCkb+Uw40j 0l3TMCkrqIPJ+1EeQKusewgHk/knpeXuqDFei/04b2TILo1RaQLwwQMyZMILozki 81Zs1bizUuU= =a02R -END PGP SIGNATURE- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Implementing batch processing for -blocknotify
On Fri, May 31, 2013 at 7:56 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Hello dear list I have an application that wants to keep up with new blocks as they come in. For that I can use the -blocknotify option with bitcoind, which will execute my application for each new block. The problem is that my app isn't necessarily quick enough to finish its work before a new block comes in and the app is executed again. This means the that bitcoind might keep executing my application even though the previous instance hasn't finished, and that's fairly inefficient resource-wise, as many instances of the application will be running simultaneously. I've discussed this with wumpus on bitcoin-dev, and we figured out a solution that might be better. It could replace -blocknotify or we could put it in a new function called -batchblocknotify Similar to other suggestions in this thread, If your -blocknotify execution is too slow, then create a solution that simply queues work. There is no need to add this code to bitcoind itself. Another solution is modifying pynode to directly listen to a trusted node (bitcoind), and monitor blocks as they arrive and are announced. That does not fix the problem of slow block processing on your side, but is another way to implement -blocknotify-like behavior. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Implementing batch processing for -blocknotify
On Fri, May 31, 2013 at 8:37 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: I've thought about this as well. It just seems somewhat clunky to me. I'd really prefer having bitcoind put out messages in batches, if it's doable, that is. I'd run into a lot of concurrency issues, as far as I can see, where I can't be sure that the queue isn't written to while, for example, it is opened by the program that needs to process the queue items. What if a disk operation takes a long time to finish, and a two queue operations want to add to the queue simultaneously? This really brings forward all the horrors of concurrent programming. This is not a compelling need to update bitcoind for this. The vast majority of systems are currently capable of processing a block, before another block arrives. As for parallel processing, your what if has been a solved problem for decade(s) now. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Tue, Jun 4, 2013 at 10:55 AM, John Dillon john.dillon...@googlemail.com wrote: I'm one of the people experimenting in this area. I've long argued that a zero-output transaction should be permitted -- 100% miner fee -- as an elegant proof of sacrifice. Unfortunately that requires a hard fork. Also, for most people, it seems likely that a change transaction would be generated. That, then, would generate an already-standard transaction, where inputs outputs. 100% miner fee is not a proof of anything because the miner could have created that transaction for themselves. You must have proof that all miners had an equal opportunity at collecting the fee, and the only way to do that is by Peter's announce-commit protocol, or his unspendable until after n blocks proposal. Absolutely. It wholly depends on the security model, and economic-incentives model. Some use models simply don't care if the miner created a transaction that gave the fee to themselves. It might even be /encouraged/ to do this! Sure they are paying themselves, but given bitcoin network difficulty is so high, simply obtaining payments-go-myself-as-miner transactions is itself difficult. Producing an identity (my goal) or whatever is just fine, and in such case becomes simply an additional block reward -- an additional incentive to buy into this identity creation/management system. Or exchange identity with another token, for another data service of your choice. This is no longer a strict proof of sacrifice system, if such behavior is encouraged, but it is nonetheless valid. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Tue, Jun 4, 2013 at 2:36 PM, Roy Badami r...@gnomon.org.uk wrote: Sure they are paying themselves, but given bitcoin network difficulty is uso high, simply obtaining payments-go-myself-as-miner transactions is itself difficult. Not for pool operators it isn't. Nor for people buying hashing power from a GPUMAX-type service, if such services still exist (or should they exist again in future). Re-read what I wrote. That's perfectly OK. It is analogous to a pool operator receiving merged mined coins, each time they mine a bitcoin block. If you achieve the very high difficulty needed to create a valid bitcoin block, you have achieved a very high bar. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
On Fri, Jun 14, 2013 at 4:06 PM, Peter Todd p...@petertodd.org wrote: It strikes me that this would work best if the pool has a mempool with child-pays-for-parent support where conflicts *are* allowed. IE you record whatever transactions you know about, conflicting or not, calculate which ones gives you the most fees/kb, and then figure out which set of non-conflicting ones are optimal. Of course, optimal is the knapsack problem... Now you can easilly tell the miners working on shares for you which tx's would be optimal if they wish to know, and at the same time whatever shares they send you are most likely to include transactions in your mempool inventory, and thus they can send just tx hashes to reduce bandwidth. Part of the broader issue that when we send peers INV advertisements we should be telling them what the fee/kb is so our peers can prioritize properly. That'd also help for the case where you want to broadcast two transactions in a row, but the pair is only profitable because the second is paying the fee for the first. Interesting proposals, particularly this last. The net result impact is, however, that which was criticized in at least one forum thread: replace-with-higher-fee. Speaking of, the way we tell peers about new blocks is really suboptimal: we tell every peer, in no particular order, about a new block via a block INV message, and then we give them the new block in parallel. I was looking through comp-sci papers on optimal flood-fill/gossip algorithms for random graph networks and it appears that optimal is to spend all your bandwidth to send the message to your fastest peer first, followed by your next fastest and so on. This works best because you get the exponential growth scaling faster by propagating the message as deep as possible in the network, and it then can flood outwards from there. Just sorting the peer list by #inv-recevied/time when doing INV pushes and when attending to incoming messages would probably be a big improvement. In terms of packet size, I would like to look into the network-wide costs of simply broadcasting block header + coinbase TX + TX list. I bet miners would love to opt into that. If the share does meet difficulty, hand it to both the pool and the local bitcoind. Should hand it to the pool first though, because the pool likely has the fastest block propagation, then hand it to local bitcoind. An optimized version may want to have some record of measured bandwidth - this applies Bitcoin in general too, although also has other issues. Currently, BFGMiner is doing submission to the pool, waiting for a response, then submitting to a local bitcoind. This is because the pool might need to receive/record the share before it processes the block on bitcoind, or you could lose credit for it. The response from the pool is rather small (a single TCP packet), so this shouldn't delay much longer. Right, I guess the pool wants to be sure you were actually the one who found the share, rather than just someone who was lucky enough to see it on the network and submitted it as your own. ## Reducing bandwidth How about for normal shares we just pass the block header, and have the pool randomly pick a subset of transactions to audit? Any fraud cancels the users shares. This will work best in conjunction with a UTXO proof tree to prove fees, or by just picking whole shares randomly to audit. Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change) for any number of shares. That's a good point - the current practice most pools seem to follow of about a share per second seems very excessive to me. On the other hand, it does have good user optics. The right solution might be something akin to P2Pool where the UI level is telling the user shares are being found so it's clear stuff is happening, but under the hood only a small subset are ever sent to the pool. With the onslaught of ASIC mining, most big pools are past a share per second. Variable difficulty or set-to-higher-difficulty quickly became the norm, almost out of necessity. Personally, I think most pools should target at _least_ 5-10 seconds per share, no matter the strength of the miner. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoind and C++ namespaces?
Slowly warming to C++ namespaces. How about starting small, and wrapping most stuff inside a bitcoin namespace? Bike shedding can be done at any point; the main idea is to start small, and gain experience. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 1:10 PM, Jim jim...@fastmail.co.uk wrote: Hello Everybody, Over the last few months we have been steadily adding functionality to MultiBit including: + encrypted wallets + sign and verify message + stability improvements and bug fixes. As a result of these efforts I think MultiBit is now suitable for the entry level Bitcoin user. I propose that we put MultiBit as the default desktop client on the bitcoin.org Choose your wallet page. I think a typical new user comes to bitcoin.org from a google search or a Bitcoin news article. We want them to peruse the bitcoin.org site and try out a wallet. They should be able to get MultiBit up and running in a tea break. Then perhaps they get a colleague to send them some bitcoin from an Android phone by zapping a QR code. This is definitely a great discussion to have. Here are some initial, unprioritized thoughts. As an engineer, there is never a clear answer, but a balance of costs and benefits. Arguments in favor of moving away from Bitcoin-Qt/bitcoind for wallet services: * Bitcoin-Qt is admittedly a very simple wallet. I see it's core strengths more as a P2P router for the public blockchain data. * Wallet feature innovation moves more slowly than Armory/bitcoinj/blockchain.info. * Requires the full blockchain, which is resource-intensive versus SPV. Arguments in favor of retaining Bitcoin-Qt/bitcoind default: * More field experience, code review and testing on desktop than others * Very real possibility of an overall net reduction of full nodes on P2P network Arguments in favor of multibit default: * Good user interface, perhaps more friendly for entry level users as you describe * Based on bitcoinj, which has field experience and a very large installed base thanks to Bitcoin Wallet/Schildbach Arguments against multibit default: * Less testing, field experience on desktop I'm sure others can come up with a few more. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] txtool: Advanced transaction building and fun
URL: https://github.com/jgarzik/txtool txtool is a command line tool written in node.js that interfaces with Bitcoin-Qt/bitcoind, to automate or assist in building interesting, unusual, complicated or just plain odd transactions. The goal is to demonstrate advanced bitcoin features, and make it easier for users to experiment. The intended audience has a basic awareness of how bitcoin transactions look and work. The theory of operation and full list of commands may be reviewed at https://github.com/jgarzik/txtool/blob/master/README Initially, two working examples are presented: * Easy multi-signature transaction building: https://github.com/jgarzik/txtool/blob/master/examples/multisig.txt (similar to gmaxwell's P2SH multisig example) * Passing around transactions (possibly multi-signature) for signing: https://github.com/jgarzik/txtool/blob/master/examples/tx-signing.txt Further examples such as decentralized crowdfunding and atomic coin swapping* will be demonstrated soon. * https://bitcointalk.org/index.php?topic=112007.msg1212356#msg1212356 -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Tue, Jul 9, 2013 at 10:00 AM, Daniel F nanot...@gmail.com wrote: on 07/09/2013 06:56 AM Jim said the following: + it will bump up the MultiBit download from about 11MB to 30-40MB (I think). This drops the maximum copies of MultiBit the multibit.org server can deliver per day from around 90,000 to 30,000ish. The multibit.org server maxes out at 1 TB of bandwidth per day. You could host your downloads on sourceforge and achieve virtually unlimited capacity. Indeed. There is no reason to worry about download bandwidth these days, for open source software downloads. Move the downloads to a site where such worries do not exist. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd p...@petertodd.org wrote: Note that with OP_DEPTH we can remove the small chance of the payee vanishing and putting the funds in limbo: What are the costs, benefits, and risks associated with scripts no longer being stateless, as OP_DEPTH would seem to introduce? -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] HTTP REST API for bitcoind
URL: https://github.com/bitcoin/bitcoin/pull/2844 Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing. Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain. The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g. GET /rest/tx/TX-HASH or GET /rest/block/BLOCK-HASH This can be easily accessed via command line cURL/wget utilities. Output formats -- binary, hex or json -- may be selected via a bitcoin-format header. The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information. There is no plan to add wallet interfacing/manipulation via this API. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
On Wed, Jul 24, 2013 at 4:28 AM, Mike Hearn m...@plan99.net wrote: Yeah, if anyone wants to make the letter more digestable please do propose an alternative, although by this point it's probably not worth it as people have already signed. I'm working on a more digestable alternative: https://gist.github.com/jgarzik/6065679 Should be ready in another ~24 hours, as its obviously incomplete right now. Alas the publishing of the lame version (which yes, I did ACK) didn't give me time to finish my version. I worked on Fedora packaging while at Red Hat, so hopefully, I have a bit of insight here. Was also thinking about publishing this on opensource.com. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor and Bitcoin
On Tue, Jul 30, 2013 at 8:41 AM, Mike Hearn m...@plan99.net wrote: * Talk the Tor protocol directly and have the app explicitly pick its own diverse set of exit nodes, one per p2p connection. This is likely to be complicated. Last time I looked Tor doesn't provide any kind of library or API. This has been discussed on IRC, and would be interesting to explore. For several applications, linking directly with a Tor library is far superior to the fragility of requiring a properly configured external process. Lacking such a Tor library right now, one must be written hint hint -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV client in pure JavaScript?
On Fri, Aug 9, 2013 at 1:58 PM, Wendell w...@grabhive.com wrote: No, it's not -- but that's certainly very cool to see Jeff. How is BitPay going to put this to use? Well, wally is just a demo application, a command line client to prove a technology. The main development is in places like node-libcoin, where a wallet platform is being developed. While maintaining a strong commitment to the blockchain engine side of bitcoind, BitPay has enterprise wallet needs that do not necessarily mesh well with the standard bitcoind wallet. Multi-sig, P2SH and other advanced features are key to the future use of bitcoin in large enterprises. Managers, CEOs and other functionaries at a corporation may each have their own wallets / keyrings, and cooperate to sign large value, high security bitcoin multi-sig transactions, for example. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Combining bloom filters?
Consider wallet A builds bloom filter A' and wallet B builds bloom filter B'. Can A' and B' be or'd together to form a single bloom filter C' ? -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Sat, Aug 17, 2013 at 8:35 AM, Mike Hearn m...@plan99.net wrote: There shouldn't be a smaller subset of Bloom filtering nodes because the idea of making it optional is a stupid one. If you're worried about DoS, come up with real fixes instead of trying to break features that work. It is not just abstract worry. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: remove getwork RPC from bitcoind
Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove getwork RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork On mainnet, almost everybody uses a pool (and therefore, not getwork directly to bitcoind). Those few who solo mine use a pool server to talk to bitcoind via getblocktemplate or other means. Tests show that attempts to solo mine on mainnet via getwork lead to delays and problems. On testnet, getwork has a better chance of continuing to work. Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork. However, at one time, getwork to bitcoind was widely used. I wanted to poke the audience, to gauge response to removing getwork. If a driving use case remains of which we're unaware, speak up, please. We don't want to break anybody needlessly. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Mon, Aug 19, 2013 at 4:33 PM, Warren Togami Jr. wtog...@gmail.com wrote: FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork. The internal miner is still actively used for testnet, here. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz mac...@bitalo.com wrote: Will removing getwork from the client impact the setgenerate RPC call? I.e. would you still be able to generate coins on testnet-in-a-box this way, or would you need a dedicated miner for that? testnet-in-a-box is very useful for testing and easy to setup, it would be great if it stays that way Yes, that is currently being discussed in a separate pull request. My pull request does not impact setgenerate, but an added proposal does remove the internal miner completely. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blockchain archival
during working hours) that to their desktop it was over 9 days before it had caught up. If all I was d/loading were the transactions since the last difficulty change (as one example of a fixed point), and the remaining balance on any not-discarded address as at that point it would have been much much quicker, and not be shagging my shiny new hard drive. There's more but it's 4.45 in the morning, and I cant think coherently until after a few hours kip and some good coffee :) Rob -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New Output Script Type
See https://github.com/bitcoin/bitcoin/pull/2738 On Fri, Sep 13, 2013 at 8:51 PM, Turkey Breast turkeybre...@yahoo.com wrote: http://www.proofofexistence.com/ and https://github.com/spesmilo/sx/blob/master/src/sx-embed-addr Embedding data in the blockchain as a hash is out there and a reality. I suggest that there should be a new payment type that is unspendable to support this. Like you have pubkey_hash, pubkey, script_hash, ..., embed_hash Maybe just a script with a single 20 byte push data. Advantages: * Optimisation possibilities (you know this can't be spent, and the script can't be processed). * Avoid indexing in an address database Bitcoin addresses which are currently being used to index data. They will never be spent, yet they will be indexed because they look identical to normal Bitcoin addresses. By separating this class of Bitcoin usage, we can improve the core Bitcoin payments system. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] the XBT
On Wed, Sep 18, 2013 at 5:16 AM, Johnathan Corgan johnat...@corganlabs.com wrote: My understanding is that XBT is a proposed standard, and hasn't been approved by ISO yet. Did that change? No. Jeff -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach andr...@schildbach.de wrote: As soon as there is a BIP70 implementation, I will begin playing with putting the payment request directly into the QR code. You may test with Bitcoin-QT right now. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
BitPay experimented with QR codes in low light, restaurant and other conditions. QR codes become difficult to use even at 100 chars. On the merchant side, we prefer a short URL that speaks payment protocol if visited via bitcoin client, but will gracefully work if scanned by a phone with zero bitcoin support -- you will simply be redirected to a BitPay invoice page for a normal browser. On Wed, Sep 25, 2013 at 7:59 AM, Andreas Schildbach andr...@schildbach.de wrote: On 09/25/2013 01:45 PM, Mike Hearn wrote: OK, it might fit if you don't use any of the features the protocol provides :) Now you're dver-dramaticing (-: I'm just skipping one feature which I think is useless for QR codes scanned in person. You can try it here: Thanks. A typical request would be around 60 bytes, which should produce an URL with around 100 chars. That should be fine for scanning, but I will experiment. If you're thinking about governments and so on subverting CA's, then there is a plan for handling that (outside the Bitcoin world) called certificate transparency which is being implemented now. Good to hear. Let's see if it gets momentum. Now when you are getting a QR code from the web, it's already being served over HTTPS. So if you're up against an attacker who can break a CA in order to steal your money, then you already lose, the QRcode itself as MITMd. Sure. I was talking about QR codes scanned in person. In the Bluetooth case we might have to keep the address around and use it to do ECDHE or something like that. Yeah, will look at that as soon as we're implementing the payment protocol fully. -- 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=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
Can you please describe more than RPC stops working? What is your precise RPC usage? getwork? getblocktemplate? other calls? What is your OS? On Mon, Sep 30, 2013 at 10:44 PM, slush sl...@centrum.cz wrote: Hi, during several weeks I'm observing more and more frequent issues with bitcoind. The problem is that bitcoind stops responding to RPC calls, but there's no other suspicious activity in bitcoind log, CPU usage is low, disk I/O is standard etc. I observed this problem with version 0.8.2, but it is still happening with 0.8.5. Originally this happen just one or twice per day. Today my monitoring scripts restarted bitcoind more than 30x, which sounds alarming. This happen on various backends, so it isn't a problem of one specific node. Is there anybody else who's observing similar problem? Thanks, slush -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
: 0.16 locktime : 0.01 calltime : 0.000359 totaltime : 0.000360 locktime : 0.00 calltime : 0.000265 totaltime : 0.000265 locktime : 0.00 calltime : 0.17 totaltime : 0.17 locktime : 0.01 calltime : 0.000488 totaltime : 0.000489 locktime : 0.00 calltime : 0.000226 totaltime : 0.000226 locktime : 0.00 calltime : 0.25 totaltime : 0.25 locktime : 0.00 calltime : 0.000369 totaltime : 0.000369 locktime : 0.00 calltime : 0.000262 totaltime : 0.000262 locktime : 0.00 calltime : 0.17 totaltime : 0.17 locktime : 0.00 calltime : 0.000459 totaltime : 0.000459 locktime : 0.00 calltime : 0.000260 totaltime : 0.000260 locktime : 0.00 calltime : 0.17 totaltime : 0.17 locktime : 0.00 calltime : 0.000330 totaltime : 0.000330 locktime : 0.00 calltime : 0.000223 totaltime : 0.000223 locktime : 0.00 calltime : 0.14 totaltime : 0.14 locktime : 0.01 calltime : 0.000449 totaltime : 0.000450 locktime : 0.01 calltime : 0.000248 totaltime : 0.000249 locktime : 0.00 calltime : 0.17 totaltime : 0.17 locktime : 0.00 calltime : 0.000327 totaltime : 0.000327 locktime : 0.00 calltime : 0.000196 totaltime : 0.000196 locktime : 0.00 calltime : 0.16 totaltime : 0.16 locktime : 0.121170 calltime : 0.000408 totaltime : 0.121578 locktime : 0.004912 calltime : 0.000278 totaltime : 0.005190 locktime : 0.00 calltime : 0.16 totaltime : 0.16 locktime : 5.996820 calltime : 0.000328 totaltime : 5.997148 -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind stops responding
On Fri, Oct 4, 2013 at 2:22 AM, Gavin Andresen gavinandre...@gmail.com wrote: RE: running into the maximum-of-4-keepalive-requests : simple workaround is to run with -rpcthreads=11 (or however many keepalive connections you need to support). I agree that the rpc code should be smarter; making the last rpc thread ignore keepalive and always disconnecting should be a fairly simple patch, and patches welcome. It's all still working around a problem unchanged since Satoshi wrote it: the HTTP server code paths use blocking I/O. Amusingly, we do this through an async I/O library, which helps facilitate SSL, but all our connections and operations are blocking. That's why RPC was multi-threaded in part: to work around the ugly blocking nature of the code. At least with multiple threads, one thread will not stall another even if the network stalls (or a software bug triggers a stall etc.) Hopefully I can dive into the code and make is truly async I/O. It takes some work, and I'm happy if someone else steals the task, but that's what really needs to be done. I tried the multi-threaded approach, writing an entire boost::asio skeleton JSON-RPC HTTP server: https://github.com/jgarzik/rpcsrv This is working, tested code that uses boost::asio properly. It's also quite a bit of LOC, and a bit messy to boot (four LOC per boost async action and incomprehensible compiler errors in return for proper async+MT). A single thread with async I/O is likely sufficient for even heavy uses of RPC -- since today it all goes through a big lock anyway. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60134791iu=/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
Continuing. (grumble gmail grumble) As with the IETF, there will be a great many drafts that do not make it to BIPS status. That is normal, and a sign of a healthy process. I'll volunteer as the BIPS editor. There needs to be some backups with commit access to bips.git, in case the BIPS editor is hit by a bus or goes crazy or on vacation. This can be some core devs, but I would like at least one or two folks who are not Satoshi-client devs on the list. Maybe Andreas, Michael G, Alan R, and others working on non-Satoshi clients. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
