+1 vector76. You posted exactly what I was going to say.

I found this interesting:
Bullish Trend supported by fully developed Head & Shoulders bottom - https://bitcointalk.org/index.php?topic=37296.0

http://stockcharts.com/school/doku.php?id=chart_school:chart_analysis:chart_patterns:head_and_shoulders_b

So far the price seems to be staying above the new "neckline" support (with pretty large demand just below the neckline) after the right shoulder.  (I think the neckline is a bit higher than shown on that chart and can most easily be seen by looking at the low points over the last 48 hours, but playing with the time period on bitcoincharts you can get a fairly good view of it as well.)  I think within the next week the price will start to turn around and head towards the mid/upper teens.  It will be interesting to see what happens.

If the theory is correct, the scammer is pork_, aka hondura, aka honduras, aka pork_honduras.

pork_ = buyer - http://paste.pocoo.org/show/403595/
hondura(s) = seller - http://paste.pocoo.org/show/403594/

IP addresses: 65.49.14.*

Here's a log of a conversation with the scammer and KCanini that just happened moments before I'm posting this: http://pastebin.com/RhSdEmxJ

Unfortunately I don't see anything where JackH (jacker224) directly communicated with any of them in my logs.  Obviously at least part of it would have been PM, if not entirely PM.

EDIT: Other nicks in my logs (which don't go back very far at this point) using IP addresses in that same range are:
titi
Miner-TE
guest1234
bridgehead
mazik

grepped log showing those nicks: http://paste.pocoo.org/show/403613/

His OTC Web of Trust ratings: http://bitcoin-otc.com/viewratingdetail.php?nick=scottlad&sign=ANY&type=RECV

scottlad is a scammer!

http://bitcoin-otc.com/viewratingdetail.php?nick=scottlad&sign=ANY&type=RECV
https://forum.bitcoin.org/index.php?topic=9045.0

What is and is not considered waste is in the eye of the beholder.

I recall MagicalTux saying (i think in IRC a couple weeks ago) that someone from Dwolla emailed him stating that the way he is using Dwolla's API is interesting and to contact them if he would like anything added to or changed in the API.

People don't pay a lot of money for crabs because people risk their lives to fish for them.
Crab fisherman risk their lives because people will pay a lot of money for crabs.

Mtgox currently has multiple bugs in the websocket's depth channel...your tables are behaving exactly the same as mine are.  Mtgox is moving to a new system in june which will hopefully have all of these problems taken care of.

Here's a naive Mt. Gox websocket client I wrote in python: http://pastebin.com/FH6eWhFm
By default it just prints out trades as they happen, but you can modify it to do whatever you want.  If someone really wants an event-based version or something to make it a little easier to work with, you might be able to convince me (with a few bitcoins ) to put something together with pywsc or something.  I may eventually release an executable jar (clojure/java) file for those willing to buy a copy that will give you a GUI to view live trades and depth changes (though mtgox's websocket is still quite buggy in respect to depth changes...there would be a button to let you do manual refreshes as well).

Mtgox has some bugs.  The websocket often entirely skips sending some depth messages, sends some at a slightly different price than what they should be, and the APIs (or site in general) has rounding inconsistencies.  I've only partially worked around these issues by rounding all depth message prices to the 5th decimal place and volumes to the 3rd decimal place, and creating a button in my program that I can click to manually refresh the entire depth tables when I start noticing odd stuff.

An example is where a bot will download it's own open orders, see that one of it's orders is something like 6.253, but it wants it to be 6.252999, so it removes the order for 6.253 and creates a new one at 6.252999, and both of those come over the websocket just like that.  And the bot does this over and over again because the API for getting your own open orders rounds to the 4th decimal place, but the websocket will do at least 6 decimal places for prices and more than that for volume, so your table ends up removing the order at 6.253 over and over again, resulting in a negative number, while it keeps adding orders to 6.252999 over and over again, making some huge number that's not accurate.  The bugs and inconsistencies are pretty annoying.

And this still leaves open the attack for flood the system with domain name registrations with no intention of buying them or using them...just to fill up space or even DDoS the network, due to the payments not being required at the time of registration.  I think I might see how the shared work can function, but it still leaves your proposal open to a very simple and easy attack unless the alternative block chain also has it's own currency and registrations come with a payment.


Some of us don't believe permission from some random person or government is necessary to register a domain name, nor do we believe anyone has a right to take domain names away from us.  I've never (at least knowingly) done anything illegal with a domain name or website, and I don't intend to.  I think the real question is why should anyone else be able to stop me from registering a domain name or be able to take it away from me?  Why should anyone even be in such a position to do that, even if they never do interfere with me?  ICANN is nothing more than government waste, like the central banks.

How do the Bittimestamp miners get transaction fees for generating Bittimestamp blocks?

First, not every bitcoin miner is going to be a domain name block chain miner, or timestamping miner, etc.  This means that to generate a block in that system that is also tied to a block in the bitcoin block chain could take significantly longer.  If you have 1/1000th of the bitcoin network's hashing power also working on the domain name block chain, then approximately 1 out of every 1000 blocks will generate a block for the domain name block chain.  Not a problem for bitcoin, but it is a problem for the alternative block chain.  If that ratio were to ever reverse to where bitcoin has the minority in hashing power, then bitcoin will suffer from blocks being few and far between.  I'm not sure that anyone has sufficiently solved this problem.

Another problem that comes from this asynchronous block generation rate is paying the miners fees for generating blocks in the alternative block chain.  Currently with bitcoin, when you send a transaction with a fee, you know the miner does not get the fee unless the transaction is accept, and the miner knows your transaction will not be accept without him getting the fee.  But with two block chains where blocks are generated at different rates, you don't know ahead of time who to send the fee to (say for registering a domain name)...the next person that generates a block may not be mining for the domain name block chain, so they shouldn't get the fee.  Someone might just assume pay the domain name miner afterwards, but this is not enforceable, and due to this lack of enforceability it opens up the system to spam attacks where someone sends a bunch of domain name registrations because they don't have to pay for them, yet, and can't be forced to pay for them in the future, but the miner's won't be able to know this, and have know way to know whether or not to put them into a block.  If they don't, they risk losing fees they could have gained...if they do, they risk filling up the block chain with useless data for nothing.

These issues do not exist when the currency and secondary application are both on the same block chain.  If someone has solved this asynchronous block generation rate issue, please point me to the post.  Perhaps I've overlooked it.  Otherwise, I believe the solution that is most likely to work for alternative applications of a block chain is for both the alternative application and the currency to be on the same block chain, which leads me to either using bitcoin, due to it already existing and thriving, or to compete against it.

I apologize for the tone, and I'll try to keep it a little nicer in any further posts.

I don't find the arguments against using bitcoin for DNS to be compelling as they all seem to be personal preferences disguised as technical reasons against it.  I'm just trying to point out that all the arguments that have been made against using bitcoin for DNS are economic arguments, which means they are based on perceived gains and loses, personal preferences, etc, and are not technical in nature.


And I should qualify this:
with: "if I were to choose bitcoin for DNS over the option of creating a competing currency."

Gains you nothing...oh, except for maybe a more robust and secure network and a more valuable and more widely used currency.  What each person loses and gains is for each individual person to decide for themselves and only themselves.  Again, please don't state your assumptions of what other people gain or lose as though it's some provable objective fact.


And the miners can and most likely will charge the fees that gets them the most profit for those types of transactions, causing the number of them to be lower than if they were free.  To reduce costs in fees, the people designing the system could provide a more cost effective system by limiting the amount of data put into the transactions/block chain to a minimum that merely references where to find the data in some other system (which is exactly how I would do DNS).  The incentives to prevent it from blowing up out of control already exist (except for perhaps the lack of flexibility for setting fees in the bitcoin client and mining software).


Scaling is generally an economic issue, not a technical one.  With enough resources you can scale anything up in an incredibly inefficient way if you wanted to (just look at most governments).  The nice thing about bitcoin is that the miners can charge transaction fees, reducing the externalization of costs to others from people putting non-bitcoin related data into the block chain, because the fees will make it cost prohibitive to just throw whatever or however much data they want into the block chain.  The miners could pick and choose which types of transactions they will put into a block according to their own economic goals, and the people making the transactions will pick and choose what transactions they will make and pay fees for based on their own economic goals.  The network will adjust and scale according to the values of its users.


All engineering is intended to meet some arbitrary subjective goal, to provide some subjective value to one or more people.  From what you have stated thus far, it seems that among your goals (preferences, values, or whatever you wish to call them) you want the bitcoin block chain to hold only data related to bitcoins, and nothing else, with the exception of making some changes to include some non-bitcoin related data in coinbase transactions.  You've chosen an arbitrary trade-off to meet your goals...some people like it, and some people don't.  Others are willing to make the arbitrary exception of just simplifying things to the point that you can include data in a transaction that references something in some other datastore.  And others are willing to go as far as putting a lot of data into the block chain (entire DNS records and other data).  Every single one of these is completely arbitrary, and the network can technically handle every single one.

The problem is not a technical one, but an economical one.  Storing large amounts of data in the block chain is likely not very economical, but the amount stored would be prevented from growing beyond a certain point due to transaction fees.  Creating an alternative block chain and making exceptions to allow a reference to this alternate chain in a coinbase transaction is certainly less burdensome on the bitcoin network, but I'm not confident that anyone's fully solved all the issues of miner incentive and asynchronous difficulty between the two chains.  Unless those issues are definitely solved, an alternative chain sharing work with bitcoin is likely to suffer and not have a chance of having widespread use.  I personally think that allowing people to put arbitrary references to outside data in bitcoin transactions makes the most sense technically (it's simple) and can be well accommodated by the bitcoin network economically (the market rate chosen by miners and those sending special transactions will regulate how much of this data goes into the block chain).



Yes, that's another reason (in addition to the one where I said the miners need an incentive to even bother creating the blocks), for there to be a fee.


It seems you misunderstood what I was saying.  I was not saying that I want to create a system where the domain names would be free, because I am already well aware that won't work.


That's awfully short-sighted of you.  For bootstrapping, sure, 'believing in "the cause"' may be enough just like it was for bitcoin.  But "this doesn't scale" to wide use of the system.  The vast increase in bitcoin difficulty is due to the fact that the price of bitcoins increased, resulting in more opportunity to make a profit from mining, leading to more people investing in mining.  In the future, I doubt most people are going to be investing in multi-million dollar data centers for bitcoin mining just because they 'believe in "the cause"', and I believe the same will be true for a decentralized DNS.  What significant reason does any other miner have to spend even just a couple hours to get setup for working on the alternative block chain if they don't already 'believe in "the cause"' and don't earn extra money from it?

Sorry [mike], it's time to rip your post apart:


The only people I've seen unhappy about doing domain name registration or other things with bitcoin are those that seem to have some sort of purist mentality in regards to which arbitrary uses of bitcoin are acceptable (according to their own subjective preferences, of course).  Regardless, please don't make assumptions about how random people you don't know will feel if someone does X or Y, and then use your assumption as an argument against some use of bitcoin.


So merchants will be ok with supporting bitcoin transactions for drugs, porn, alpaca socks, and their competitors, but not for domain names?  What's the difference?  If a domain name transaction can be done using practically the same amount of space and computational power as a normal transaction for any other good, then why does it matter?  If the merchant is ok with processing bitcoin transactions that go to their competitors (and the blocks holding those transactions), then why would they care about processing transactions with a few bytes of extra data for domain name registrations?  Either way from their perspective it's just bandwidth, processing power, and storage being used up for things that do not pertain to their business...  Why would they single out domain name transactions as being unacceptable, but tolerate all the other millions of bitcoin transactions that provide no income to them but cost them resources?


How can you decide who it does and does not hurt or if it will increase or reduce the number of merchants?  Like I said, they're willing to tolerate transactions and blocks containing transactions to their competitors or businesses/people that aren't directly competing, so why would they single out domain name transactions?  Perhaps registering domain names through bitcoin increases the security (more miners due to higher fees for domain name transactions) and value (by adding decentralized domain name registration as another use) of bitcoin...is it impossible, or even unlikely that some merchants won't find that increased value more than enough to offset the increase in transactions of similar size to any other transaction?


And this will have to be done for every bitcoin transaction that's buying a domain, whether or not the actual domain information is in the transaction or not. 10000 bitcoin transactions buying domains from some centralized domain name registrar, or 10000 bitcoin transactions containing perhaps a couple more opcodes and a 32-byte hash referencing the domain name the registering has no practical difference in computational cost (and I think some have presented ways to do it without increasing the size at all).


I care about his technical opinions, but I don't recall him presenting any technical reasons for not putting non-bitcoin related data into the main chain.  I think it's purely an economic issue (one I believe most people will view as a net gain), not a technical one.  This means it is merely a matter of personal preference.  Just because Satoshi's preference was to keep non-bitcoin related data out of the block chain does not mean that putting that data in there is not a good idea...it just means he doesn't want it in there.  It's no different than you wanting or not wanting pineapple on your pizza.


It's not because people want to pay for domain names (I think most people, including myself, would much rather get them for free than pay for them).  It's because there needs to be an incentive for people to work on the block chain.


So you leave out the one that actually gives people incentive to work on the DNS block chain...  Obviously you're under no obligation to provide such a solution to us, but it's the most important part!  You went through all of this trouble making this post, but left out the most important piece.  Without it, a decentralized domain name registration project will not become widely used.

If two different block chains were to be used while sharing work and providing an incentive for the miner to support the secondary block chain, the domain name block generated has to be synchronized with the bitcoin block that holds the transaction paying the miner.  If they are not synchronized, the miner is not necessarily guaranteed to be paid for registering the domain name (requiring that registration to be considered invalid, and wasting work on the miner's part for including it, not to mention the block chain being wide open to spam due to not needing to pay to get transactions put into it).  The person buying the domain name can't pay before the block is mined, because they don't know who will mine the block until after it happens.  The simplest way to solve this is for the domain name registrations and fees paid to the miners be in the same transactions on the same block chain.  This means either doing it in the bitcoin block chain, or creating a (probably more valuable) competitor to bitcoin that will provide a greater incentive for miners to stop mining bitcoin and start mining in the new system...not good for bitcoin.


I have to question whether or not you really understand the issue with domain name registrations and bitcoin.  You're using personal preferences as reasons to not do domain name registration in bitcoin, while providing unnecessary technical alternatives (that do not provide the necessary incentives for it to work) just to meet your personal preferences.  For you to even think that people "want to pay for domain names" and then going through the trouble of providing a technical way to do this proves your lack of understanding on this matter.  You're willing to make modifications to bitcoin to accommodate alternative block chains, but are not willing to allow a few extra bytes in a fraction of the transactions, requiring no change to bitcoin and likely providing an economic benefit for most/all people using bitcoin through more mining incentive, thereby increasing network security, and also through more demand for bitcoins due to it's use for domain name registration.

The issue of using the bitcoin block chain for domain name registration is not technical.  It's purely an economic matter, meaning it's entirely subject to personal preferences.  Please don't hide behind Satoshi's opinions or use unnecessary (and unsatisfactory) technical alternatives as a way to suggest to us that your anti-DNS-in-bitcoin post is anything more than an expression of your personal preference.  Also, please don't state your assumptions as to how it would affect others economically or emotionally as though it's some sort of provable fact.

It appears that you fixed the dark orders ok (at least the dark asks...I got an error when I tried to make a dark bid, but I have to play around with that to see what the error was since my GUI currently doesn't display error messages to me, yet.)

The orders with insufficient funds still seem to have some problems, though.

I tried an ask of 2000 @ $4, and I only saw the amount I had funds for come across the websocket, but when I canceled both orders (the one with the funds, and the one without), they both came through the websocket as two negative asks @ $4 totaling to 2000.

I then tried a bid of 2000 @ $1, and I only saw the amount I had funds for come across the websocket, but when I was viewing my orders through the old API, I only saw one order of 2000 @ $1 marked as not having sufficient funds (seems to be an unrelated problem to the websocket...I do have funds to cover part of that order), and when I canceled it, a bid of -2000 @ $1 came across the websocket.

So the depth channel is still causing some inconsistencies, but it's definitely improved.  I think there's also the occasional issue where a the price of a trade doesn't exactly match the price of the bid or ask being removed from the depth tables.

Also, I agree with jed that being able to get the current depth table (as well as trade table, and my own full order list) through the websocket instead of the old API would be an eventual nice-to-have.

Thanks for what you've done so far, though!

@MagicalTux

When do you think you'll be able to stop broadcasting dark orders and orders with insufficient funds on the websocket?

That's the risk with making a top-down decision for a system wide TLD instead of letting people choose their own TLDs and taking the risk individually.

The approach I'm going to take (unless I decide I like your project enough to halt development on mine) is to not set a global TLD for this system, but let users register their own TLDs.  The resolver would by default give priority to ICANN TLDs over those from the distributed system (to make the transition smoother for normal people who might not be quick to stop using com/net/org, etc).  Users would be able to change a setting if they wanted to ignore all ICANN TLDs, or choose certain ones to use/ignore.  All of the DNS information for TLDs and sub-domains would be stored in a DHT, and the DNS settings on the user's machine would point to a locally running DNS server which acts as the gateway to the DNS info stored in the DHT.  I'm not going to choose a TLD for everyone else, and TLD conflicts between the system and ICANN can be resolved by the users of the system, without relying on me to fix them.

The decaying network fee idea is interesting...I'm not sure what I think about it, yet.  How many namecoins will the system create?  Is there a set limit like bitcoin (I hope so), or will they be generated forever?  Are the namecoins destroyed by the network fee ever replaced (not that I think they need to be)?