I was also deleted, posted this:


in the litecoin is officially dead thread

I wasn't going to say anything until rikkejohn mentioned this thread.

Uncertain why I was deleted, honestly don't really care, but it's a strange reaction to a rational comment.

You could fuse the localbitcoins approach with an exchange, trading is more latent but works.

Traditional order book.

BTC consumed by an order is held in escrow, purchasing entity has bank details provided to them automatically, sends funds, bitcoin released. Do the opposite at another site operating in the same way.

You could probably drop the latency to a few minutes in some cases.

This method assumes entire balance trades.

If you are only trading with a percentage of your stock then you can use caches at each exchange to perform this function easily, then balance your own books in a more latent fashion.

Example: 10 BTC and $5k on two exchanges. Sell 5 BTC on one for $3000. Buy 5 BTC for $2900 on the other. Balance on one exchange is 15 BTC and $2100. On the other 5 BTC and $8000. Not taking in to account fees. You've successfully arbitraged $100 profit. You can either wait until the arbitrage is available the other way, or swap balances in a traditional withdraw/deposit way.

Thank you for posting this, exactly the information I was looking for, has saved me some work.

It was 5 BTC when I first used it. I moved the funds to a mybitcoin.com wallet. They were lost forever.

I've added https://github.com/coinsolidation/bitmark/wiki/Scratchpad a place for some thoughts. Copied here:

Thoughts which need fleshed out

* Option to run on Random Port instead of Static.
* x509 certificate based authentication for http+tls api
* focus on https+tls (https) api
* modular extensible design, focus on light fast daemon where apps interface through api
* web based management interface, needs tight security, consider apps as agents with their own auth details
* ui easy to access like webmail, hooks in to the api of whichever node is specified
* bitcoin's old ip transactions is an abstract request payment address api which could be updated and run with urls
* one time addresses can be proven by provider signing it with a key they are known to own
* need neat api call to show chain download progress, block xxx of yyy
* maybe x509 certificates can be used to provide rsa encryption for messages, so messages are optional and require no processing weight to clients, but can be access if available and supported.
* signing one time use addresses is important, prevents against mitm attacks on payments
* messages relating to transactions can be detached and sent by different communication methods, a hash of them can be put in transaction as proof of their validity
* worry over reliance on dns for dnsseeds, there should be another way
* bitcoin design was based on everybody running a node, block time had to account for huge network latency, with increase in spv clients and api clients it can rationally be decreased
* existing services are important, but new services can be created to accept bitmark, file hosting is always important
* faucets which deliver free coins that can be used to purchase real services drives adoption, ensure rate limiting by ip address subnets
* api integrations are important, adding bitmark support should be as easy adding a wordpress plugin
* uri scheme for sending payments which can invoke specified client is important
* look at transaction notifications api, perhaps push instead of listtransactions/getbyaccount, perhaps transactions since x
* check if javascript apps can post to localhost, could be nice for detached clients
* institutional momentum is to stick to the last decision made, so bitmark should be secure before targetting existing service providers, if they deny it first time they will probably keep denying
* api documentation should include example code for well known language(s), important to have before pushing adoption
* people should not need complicated tooling to fix stuck transactions and errors, there should be an easy way to do it automatically
* ensure json-rpc over http is http compliant
* does caching need covered, in daemon, or as a layer above, perhaps a wrapping application that caches json responses and acts as a middle man
* simplicity first, the network only needs to prevent against double spends, if it does that, and people can interface easily, it works.
* discuss starting with a fixed reasonable transaction fee
* make block chain downloads available at each checkpoint?

any discussion is welcomed.

Is there a sweet spot for number of connections and distribution of those connections around the physical world (well by ip ranges).

I guess there must be a number range >1 which balances network traffic with latency to provide the most effective experience.

Any comments or existing discussion on this?

Has anybody implemented (in any alt) x509 based authentication for use with HTTP+TLS over the JSON-RPC api?

Coming back to this. I've noticed an abundance of threads like this. To me they read that there's a growing and improving amount of scrypt hardware out there, which can be used to secure the network. Combined with the user focussed approach to make Bitmark an every day usage coin, it appears all the elements are there just waiting to be utilized.

Financial agents do not need to be human, many benefits come from automated agents bearing keys.

Competition between development teams brings evolution to the technologies involved.

Technologies from other sectors such as nymi can be used to tie human agent identities to assets.

It is nice to build a system based on ideals, but if it does not model or account for reality, it will be abused.

PoW replaces the human cost of automating a ledger with a computational cost. As the ledger grows so does it's cost. It's cost is required to mitigate attacks. It's cost would be higher if it was a human process.

Blockchain/crypto based solutions allow computational agents to do a trust-based human task, freeing humans to do other things.

If we can apply this to all aspects of "work", life will improve for all.

mining profitability is determined by currency value proposition to end users, if it has none profitability will decrease and become loss.

hashing algo does not matter, currency utility matters

False.

The reason it's unprofitable is because Litecoin doesn't focus on anything really. If it was a daily use currency with people using it as money, it's value would be increasing keeping, or making, mining profitable.

If each LTC was worth $20+, you would not be saying this.

that was beautiful.

You're called PoS? lol

Anyway, PoS as specified and implemented by sunny is rather good.

PoS used as an excuse to premine and make a few rich, or as an "after thought" to make a few early adopters hold the bulk of the coin, well that's not good.

I think we could make this simple, any coin who takes any step to ensure distribution is not fair, is not a fair coin, and is in a very gray place. Which is almost all of the coins. LTC, BTC, PPC and a few others are fair, the rest, well they just have no longevity.

some observations.

• by dumping the coin you create new bagholders, so new people have the coin and will need to either dump it, or make it rise again
• people can already manually do this with any coin simply by selling it and using the proceeds to buy another coin
• anybody could create a new coin and create a shitcoin/newcoin, newcoin/btc exchange
• this is open to massive manipulation, if an entity wanted to acquire a huge amount of x-coin they could deem it shit, acquire it all at the lowest price, then make the coin unshit and execute a social 51% attack
• any really shit coin already has zero value and zero orders, so it can't be dumped and turned in to coin shield
• the model is centralized and trust based, trust you with most of the btc from each shitcoin
• the idea of a well known service which immediately classifies new coins as clone or innovative would serve the purpose better, and prevent people from investing in new scams, rather than forcing them to commit to a loss and creating new bag holders
• the countdown, the promise that early traders will make the most profit, the focus on acquiring btc, has all the hall marks of every shit coins produced, and does you no favours
• the coin has no value of itself, no long term incentive, and will be deemed to be a shitcoin itself, with early adopters having guaranteed btc orders to dump in to once they reached their target profit margins
• needlessly complex for such a simple proposition, these complexities don't add value, they detract

The thing you are trying to achieve is fairly decent but creates the problem, old bag holders swap to new bag holders, and it's open to exploit, as is your own coin.

If you could codify this in a different way, without it being a coin, perhaps just a well known coin index and voting system, you'd achieve more with more benefit to the community.

I admire your efforts, but worry as above.

Bitcoins top 100 accounts (including the big bitstamp one and the seized coins) constitute 20%, the top 500 32%.

source: We suggest that humans tend to prefer whole numbers, and feel more comfortable working with smaller integers on a daily basis.

Okay, that's good enough for me. I'll do the numbers and refine.

Thanks for your input!

This is a good question, thank you.

I have not yet decided exactly which block reward will be the last, or whether to just keep halving until it's infeasible to halve any more. After a certain point when transactions are covering the mining costs the block reward is more of a bonus.

Is there any reason you feel a round number would be better?

I can do the numbers and work out the final few block rewards and assign a cut off block which equates to a round number. Potentially a round number of Marks, so 27.5xx million coins, to three decimal places.

Thank you for your replies.


It would be nice to keep things as simple as possible. With three primary units. 1, 0.001, 0.000001. Each one relating to a potential parity milestone.

For common usage, each primary unit could have cents, as we experience commonly in life.

Using the existing proposed language:

• 1. 1.9x Bitmark
• 2. 1.9x Mark
• 3. 1.9x Markbits

So I guess a name for the "cent" (x above) in relation to each primary unit would be good.

1. I will suggest that whilst dealing with entire coins people are familiar with 8 units of precision, and thus we do not need a name for the first case.

2. Is may be the most common, I like your suggestion of cents, Markcents. This makes sense to me.

3. The final unit with two decimal places (currently called a markbit) has a cent value which corresponds to a satoshi.

I feel milli, and micro, in relation to currency conjures the notion of limited or meaningless value. Even though as a programmer I like the terms.

This must appeal to a wider audience.

For now perhaps Bitmark, Mark, and MarkCent are enough to define. Do you agree?


If we consider coins with longevity in mind. Bitcoin and Litecoin, ASICs have done much to solidify the networks strength. With natural sustained growth I hope the hash rate would continue to rise. Scam, clone or pump and dump coins have problems with them, but this is not such a project. There has been a substantial investment in mining hardware for scrypt based coins, we should not ignore this, and I feel there is an opportunity to put all that hardware to good use, a use which secures the network and gives investors in this hardware a return on their investment.

My main concern is really the first day(s). For this reason I propose a high diff to start.

1. ASICs should ensure each party get's a more even share of the block rewards.
2. Net benefit, and strengthen.

Ask this question in relation to bitcoin, same answers apply.

Please do keep questioning and discussing, and thank you for your replies

edit: from another thread.

I've been researching this recently.

My conclusion is that no stable coin with longevity in mind has yet successfully migrated from block reward to transaction fee remuneration.

Bitcoin should be well on the way to migrating to transaction fee funding of miners by about 2030.

I am currently specifying and developing a currency which aims to do this migration 10 years earlier and should have completed migration before bitcoin really starts.

I've included rationale for each decision in my writings, if you'd like to discuss any of them in relation to bitmark, or just in general, I'd be more than happy to join you.

I am hoping to identify a fair and reasonable starting difficulty on a scrypt coin.

Previously I've suggested


Can anybody share any insight they may have as to an estimated hashrate for the first day of a new, decent, scrypt coin. I'd rather it was higher than lower.

Thank you for any discussion.