Guys, stop with the ad hominem attacks. No need to bring in other projects or PoB into this discussion. Though PoB offers certain trust advantages when it comes to migrating from an existing cryptocurrency chain, it is by no means necessary as a means to establish trust in an IPO funding scheme. (In any case, Ethereum will be dependent in BTC at least initially, because, well, the buy-in is in BTC. Duh. Gradually as mining is established, I believe it is the dev's intention to move away from that dependency). Also, a distinction has to be made between a initial PoB buyin (ala XCP) vs. a continuous PoB scheme (ala Iain Stewart); vitalik's comments addressed the latter. However, the community as a whole would appreciate more details w.r.t. how the "holding entity" is structured, and who exactly controls it. I assume that these details will be forthcoming. Specifically more clarity on: We will likely use 3-of-5 multisig to hold our funds. We will be the first cryptocurrency fundraiser that we know of whose exodus address actually has a 3 at the beginning. is welcome. The maximum number of coins is also irrelevant (aside from technical reasons), particularly as mining output scales linearily with the amount of the initial stake. Does it matter if bitcoin has 21,000,000 or 21,000,000,000 coins, if everything is scaled up similarily? |
|
|
|
|
Update on trying to compile this for windows:
1. Installed go, mingw-x64 (first installed the x32 version, then realized that that was wrong), gcc, make, etc
2. Installed MSYS
3. Installed, configured, and compiled gmp-5.1.3 (currently sitting in MSYS home directory)
4. Linked the compiled gmp-5.1.3 to the compiler w/ LIBRARY_PATH. Se GOPATH to c:\ethereum.
5. Tried to run, and comes up w/ this error:
C:\ethereum>go get -u -t github.com/ethereum/go-ethereum
# github.com/ethereum/go-ethereum
__gmpn_tdiv_qr(0): not defined
__gmpn_get_str(0): not defined
__gmpn_add_n(0): not defined
__gmpn_copyi(0): not defined
__gmpn_mul(0): not defined
__gmpn_gcdext(0): not defined
__gmpn_sub_n(0): not defined
__gmpn_rshift(0): not defined
__gmpn_set_str(0): not defined
|
|
|
|
I saw this in the github; may be of interest. ----- Purchase steps At start of fundraiser User sends value to intermediate Bitcoin address Server sends from intermediate Bitcoin address with the following outputs - Ethereum exodus address
[1] The hash160 that is your ethereum address
[2] The hash160 of your email address
Store users's email address along with its hash160 in mongodb
2 months later:
Ethereum looks up your email address and sees if you got a reward
|
|
|
|
Sorry guys, looks I broke something again ....  Apparently 100,000,000,000 is too big of a number for coins. "I was just trying to recreate DOGE .... *slinks away*" (Wow, how many bugfixes did I cause in github today? lol) Still .. better that these things happen now than in the future, where things will seriously break.
Note: I would suggest a max cap, because no matter what datatype you use, someone could simply issue 999999999999999999999999999.... coins as an attack.
I haven't tested non-alphanumeric characters in the asset name yet -- is there support for that or will I crash something again?
Absolutely. Keep 'em comin'. I fixed the code so that it will run, but this same problem may exist elsewhere, so hold off on re-creating the problem for another twenty-four hours, maybe. Asset names should only be upper-case alphabetic, but the code should catch all violations of that rule. Thanks for taking care of this right now. I won't cause any more mischief tonight ... :p |
|
|
|
|
Still .. better that these things happen now than in the future, where things will seriously break.
Note: I would suggest a max cap, because no matter what datatype you use, someone could simply issue 999999999999999999999999999.... coins as an attack.
I haven't tested non-alphanumeric characters in the asset name yet -- is there support for that or will I crash something again?
Also check for overflow possibilities in trading, dividend payments, bets, all that.
|
|
|
|
Sorry guys, looks I broke something again .... Apparently 100,000,000,000 is too big of a number for coins. "I was just trying to recreate DOGE .... *slinks away*" (Wow, how many bugfixes did I cause in github today? lol) |
|
|
|
Basic questions:
1. Where is the data stored? How much redundancy? Obviously you need data to serve content.
2. How do you ensure that users are actually serving the correct data?
3. How will you validate the amount of data being served? (Imagine that an attacker controls both sending and receiving nodes. It would be trivial to fake the amount of bandwidth "used").
4. What types of data will you disallow? (This has many important legal consequences, as I'm sure you can imagine.) If everything is "allowed", I'd imagine most users unwilling to participate in fear of lawsuits/retaliation/subpoenas.
5. What is a "coin"? (unit of storage/bandwidth?) What is "difficulty"?
3. Nodes cannot cheat the system because there are multiple nodes sharing the same file. The node that the user connects to is chosen at random. Edit: Decided to go ahead and answer number 3. I assume this is a torrent-like scheme where files are broken into independent, verifiable (by hash) pieces, is that correct? Storing data in nodes seems to assume unbounded storage space. How will you make sure that nodes actually have the requisite storage space? Particularly important for high bandwidth, storage constrained systems (I'm talking about VPSes, of course, which will probably be the source of the majority of the bandwidth). It seems like this could be used for nefarious purposes (I'm talking about DDoS); will there be measures to control how many coins a potential attacker can get and/or use at the same time? It also seems like at least in the beginning, the system will not come close to even saturating bandwidth. In that case, what determines who gets block rewards? Random chance? Latency? |
|
|
|
|
Basic questions:
1. Where is the data stored? How much redundancy? Obviously you need data to serve content.
2. How do you ensure that users are actually serving the correct data?
3. How will you validate the amount of data being served? (Imagine that an attacker controls both sending and receiving nodes. It would be trivial to fake the amount of bandwidth "used").
4. What types of data will you disallow? (This has many important legal consequences, as I'm sure you can imagine.) If everything is "allowed", I'd imagine most users unwilling to participate in fear of lawsuits/retaliation/subpoenas.
5. What is a "coin"? (unit of storage/bandwidth?) What is "difficulty"?
|
|
|
|
|
Devs,
I get this when trying to recreate the database:
C:\counterpartyd>python counterpartyd.py server
Status: RESTART
Block: 280518
Traceback (most recent call last):
File "counterpartyd.py", line 618, in <module>
blocks.follow(db)
File "C:\counterpartyd\lib\blocks.py", line 479, in follow
raise e
File "C:\counterpartyd\lib\blocks.py", line 472, in follow
parse_block(db, block_index)
File "C:\counterpartyd\lib\blocks.py", line 57, in parse_block
issuance.parse(db, tx, message)
File "C:\counterpartyd\lib\issuance.py", line 103, in parse
util.credit(db, tx['source'], asset, amount)
File "C:\counterpartyd\lib\util.py", line 160, in credit
assert asset != 'BTC' # Never BTC.
AssertionError
|
|
|
|
|
For IPOs - requirement for source or working client demo. Screenshots are doctored far too easily. Most coins though don't even go that far.
|
|
|
|
Agreed. There is no free BTC.
You spent yours trying to multiply it, and by being a greedy fool.
He earned it by taking another kind of risk - traces of this "IPO" will remain on network, and one day... well you never know how this might end up.
It's not like we didn't warn you.
Karma can be a patient maiden... On the other hand ... people are SERIOUSLY still sending this guy money?  |
|
|
|
Thanks for the link. "The client can't spend just 10.00 BTC out of a 10.89 BTC payment anymore than a person can spend $1 out of a $20 bill." So I guess this is one aspect about Bitcoin I didn't grasp before now. Which reduce quite a bit it's awesomeness I must say... Maybe it's because I made most of my transfert from online exchange and wallet. Where it's not a problem to send 1/10 of my coin, and just 2sec after send 2/10 of the rest elsewhere. I'm not froze for a blocktime. Yeah I got it now. The abstraction of online exchange hided this "default". At least it send the change to the same pubkey, and not randomly-without-control like bitcoind. True, this is one of the more "confusing" aspects of bitcoin that is not exposed (generally, and for good reason). For protocols that push the envelope (i.e. XCP), you inevitably start to encounter these things. The default bitcoin-qt actually sends change to a DIFFERENT address as you said (arguably for good reason - to increase anonymity), which has lead to hundreds of real BTC lost from people who import in and delete their wallets, who don't realize this. (Blockchain.info does not do this). |
|
|
|
.0001 is an absolutely insane starting price for a coin that will eventually have 1 trillion in circulation.
This is a concern. What about a funding approach that releases tranches that people can bid on? The release dates would be of equal proportions, well defined (i.e. 1 "unit" of coins released at 0:00 GMT each week). People would submit bids in a sealed-bid (to address cries of "market manipulation") dutch auction, and winners would be allocated shares from highest bid on down. |
|
|
|
From http://wiki.ethereum.org/index.php/Dagger: ...In the context of mining, however, botnet-infected computers tend to be running older operating systems and have weaker specifications, meaning that they will have a much lower performance and impact on the network than their size might initially suggest.
...
...
...
...And even in such an equilibrium, mining with ordinary CPUs will likely continue to be practical. So we have such a formula for mining power: numberOfZombieComputers * X = numberOfLegitMinersQuestion: What is ur assessment of X value? it start with "0." X = [0,1) |
|
|
|
The transaction looks right, but the TEST/XCP value from the log looks wrong, again.
Also on blockscan:
- "Price" should include the pair (e.g. XCP/TEST) instead of just "XCP"
- For BTC/XCP, buy and sell prices look right; the "price" column is still wrong (you could derive/verify the price column by dividing the buy by the sell price...) - more confusingly only some of the prices look wrong.
(I hope this "intensive" testing is useful, BTW).
Yes, I am currently working on the order display and have updated the latest changes.. I believe I am getting closer :-). I have swapped columns for the buy/sell so that it follows the sequence of the "order" parameters command. Every order is a "buy" first The buy prices are actually available in the order database so I am picking those up from there. However, I believe the divisibility (0 or 1 value) of NON BTC/XCP Assets can be set on a per individual basis when the asset is initially issued(generated). I suggest also rebuilding the db from your end. |
|
|
|
Unfortunately I don't think bitcoin works that way. When you are trying to send an amount (0.0002172) that does not exactly match an unspent output, a transaction has to be made that takes the remaining amount and sends it back as change. The "problem" is that the amount sent back as change is unconfirmed, and counterpartyd does not allow spending of unconfirmed outputs (while I think the main client/blockchain.info does).
I did not understood the beginning. Maybe on a technical point of view it is hard or not possible in this case to not have change, I don't know. Understood last part. What I don't get is why *all* BTC must be moved. No change = no need for confirmation = annoyance solved. avkinp, we're around 1300 XCP/BTC now This is just how bitcoin works, after all. Does this help? https://en.bitcoin.it/wiki/ChangeThere used to be a picture somewhere... |
|
|
|
Example: pubkeyN has 1000 XCP & 1000 BTC, send-cmd cost 0.0002172 BTC
if I enter the command to move my XCP, all these BTC are frozen...
why does the other 999.999 BTC need to be unavailable for 1 blocktime?
awesome if you can improve that by stopping to move what doesn't need to move
just take the 0.0002172 or what it will cost in v0.9 with OP_RETURN (back to 0.0001 BTC I hope)
If I moved 500 XCP, I need to wait 1 blocktime to be able to move other XCP => annoying
Unfortunately I don't think bitcoin works that way. When you are trying to send an amount (0.0002172) that does not exactly match an unspent output, a transaction has to be made that takes the remaining amount and sends it back as change. The "problem" is that the amount sent back as change is unconfirmed, and counterpartyd does not allow spending of unconfirmed outputs (while I think the main client/blockchain.info does). |
|
|
|
|
Show Posts
