An address seems to have been posted on the i2p site: http://www.i2p2.de/donate.htmlUnfortunately... it is neither of the two addresses posted so far... I hope the situation with "max stirner" is resolved - hopefully he's legit and will forward the donation to the i2p project... otherwise... i guess we can let that be a lesson that a donation address is not a valid address until posted on the official project site... |
|
|
|
grondilu: by the way, i have created the #bitcoin-auction channel for conducting irc auctions. should be a fun place, once more people start auctioning their stuff. in the meantime... you're welcome to use it for your coin auction when we approach block 100k.  I usually create a specific chann but if I'm welcome on #bitcoin-auction, ok why not. Thanks. yea, i just thought having a stable channel for auction would create more of a permanent user base, and thereby possibly more action on any given auction. |
|
|
|
it was just a bid... also, prices on mtgox are, fyi: "buy":0.208,"sell":0.2278 if you see someone buying at .3, let me know  |
|
|
|
Usually, when a bank run happens, it cause the bank to collapse.
since mtgox promises to cover the paypal held funds (and i, for one, trust his promise), this would not happen with a run on mtgox. |
|
|
|
So who did I donate to? The Max Stirner Foundation? haha, seems like it.... |
|
|
|
The bitcoin client generates a new bitcoin address every time a donation is recieved to an old one (to make spying on peoples finances with the block chain more difficult). I have 2, my starting one and the one that was generated after I got my faucet bitcoins. So if echelon reopened his bitcoin client when he sent the email he would have sent a different address.
no it doesn't. you can receive on a single address multiple times. |
|
|
|
grondilu: by the way, i have created the #bitcoin-auction channel for conducting irc auctions. should be a fun place, once more people start auctioning their stuff. in the meantime... you're welcome to use it for your coin auction when we approach block 100k. |
|
|
|
<some stuff> besides the possibility of storing NS records in addition to just registrations... the theymos+nanotube spec does exactly what you suggest. |
|
|
|
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
Same incentive as the main chain -- you get paid. but if you get paid just as much by mining pure bitcoin without the side hashing... |
|
|
|
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
sounds excellent in theory... The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ? very curious to hear your further thoughts on this. |
|
|
|
read my post up, program will behave like people are really buy/sell. If i can do it, just think what this japanese bitcoin father can do
indeed, it's possible that mtgox is filled with 'shill offers'... that doesn't really change anything. if a shill-offer is offering to sell bitcoins at .20 usd/btc... and you accept it, you just bought some btc at .20. it doesn't matter if it was from a 'real person' or some 'puppetmaster' who is orchestrating a bunch of shill offers. in fact, there probably are some offers being managed by trading bots... just like on "the real stockmarket". as long as trading is going on at price X, that is de-facto what the 'price' is. |
|
|
|
Didn't realize that they weren't doing distributed registration. And bitdns only does Domain Name Registration?
My DomainChain proposal most definitely only addresses Domain Name Registration, although I expect that one or more generators would run DNS servers to validate the concept. The theymos/nanotube proposal makes several references to servers, but they would need to clarify what they have in mind. what we have in mind is that anyone can put up a dns server at a moment's notice, by just reading the appropriate window in the block chain, and populating their dns database. so in effect, our system is also just about registration - the dns servers are separate entities, that simply read the protocol, and convert it into standard DNS record format to serve. we talk about dns servers as they'd be necessary to 'complete the loop' in making a usable system, and we plan on releasing code for a reference dns server, so that they can spring up all over the world - but strictly speaking servers are separate from the bitdns protocol itself. |
|
|
|
|
yes, #bitcoin is best, /if we can get it/.
according to my information at the time of posting this poll, the group registration process was backed up for /years/, hence my desire to use another channel rather than waiting for all this time.
some more recent information from jgarzik suggests that it may be possible to push it through within weeks - if that does turn out to be the case, of course #bitcoin will be the channel of choice.
|
|
|
|
This was touched upon in the original mega-thread for BitX, but it's worth restating here simply.
Basically a BitX block looks something like this:
<hash of previous block (BitX backlink)>
<hash of bit-foo name> <hash of bit-foo block> <bit-foo backlink>
<hash of bit-bar name> <hash of bit-bar block> <bit-bar backlink>
... and so on for each bit-app ...
<timestamp>
<nonce>
Notice that no app-data is present in the actual BitX block. The app blocks are separate although probably are distributed in the same way as the BitX blocks.
<snip>
who generates the bit-foo blocks? who ensures the integrity of the bit-foo block chain? in order for the hash of bit-foo block to be actually linked to the backlink... something somewhere must be storing that data, and verifying the hashes... further, and possibly more importantly, to prevent double-spending attacks on the bitfoo chain, the bitx generators must be able to deep-inspect the content of the bitfoo block, to make sure there are no double-spends in it. this means that with your current setup, bitx is /not/ in fact app-agnostic, but must know about the details of every foo/bar app that's trying to get in. |
|
|
|
consider also that it's possible to encode data into the bitcoin blockchain already, merely by specially crafting the transaction. (See the 'first' option on http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity ). alternatively, only timestamping and proof of expense (i.e., a regular transaction with a fee) may be used, pushing off the actual data storage off to external service (see 'third' option, ibid.) but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power. |
|
|
|
Thanks for the backup. :p
Yes, I think that the different bit-apps should be as orthogonal as possible, both to each other and to the "uber-chain" of BitX.
Honestly, bitcoin may not be the killer app for the block chain platform. If this is the case then we run the risk of a more popular app leaving bitcoin in the dust, and then having someone incorporate a currency platform into that app, thereby dwarfing the bitcoin block history and popping the bubble.
That's why I think it's essential to "bind the fates" of the various bit-apps together in a single BitX "uber-chain" that can provide mutual protection for bit-apps like bitDNS and bitcoin as well as easily foster new apps.
you seem to be suggesting that somehow there would be a general "bitx" chain, which all the different apps use, and thus there's no fragmentation of cpu power. sounds theoretically nifty... but how would you achieve that? the point of bitcoin is that it makes it expensive, and verifiable, to insert data into the chain. if you have a separate chain that doesn't actually have any data in it... then how do you tie the 'apps' into it? it seems that you have not offered even an inkling of an approach that would make it possible? or am i wrong and i missed something in the upstream post? |
|
|
|
if it happens, that'd be great. if not... we'll have the results of this poll to go on. |
|
|
|
|
Some background:
The #bitcoin channel on freenode is orphaned - we have no ops, and due to freenode's group registration being pretty much dead, are not about to get them any time soon.
For now, community discussion has been going on in #bitcoin-dev, but as our user base grows, it will be helpful to separate general discussion from development-related discussion.
To this end, we need to create a channel for non-dev IRC chatter.
If you are an IRC user, please vote on the alternatives, or suggest a new one.
|
|
|
|
|
Show Posts
