Bitcoin Forum
January 28, 2022, 02:40:21 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Pizzacoin with Innovative Proof-of-Pizza on: March 26, 2014, 09:31:01 AM
It appears as if a double spend attack is not entirely undesirable.
2  Bitcoin / Legal / Re: IRS Releases Tax Rules on BTC on: March 25, 2014, 08:29:04 PM
the power elite have succeeded

bitcoin is effectively banned


No, America sees the glimmer of bitcoin and wants in.
by making bitcoin so difficult to transact in it's impossible?

have you ever filled out a tax return and had to report capital gains?

no?

Hmmmmmmm.
3  Bitcoin / Legal / Re: IRS Releases Tax Rules on BTC on: March 25, 2014, 08:24:35 PM
the power elite have succeeded

bitcoin is effectively banned
4  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Nome Coin on: March 24, 2014, 07:24:56 AM
Just do it.


well, in the past week I've downloaded winmerge and grepWin. I can't say I'm familiar with C but I can read it. (I'm a typical altcoin developer from the looks of it, not that Bitcoin or Dogecoin devs made multiple bad commits in the past)

It appears in order to create a new coin, I'll have to change various checkpoint and genesis block parameters around. Uncertain fully of the tasks required. I will likely release the code for public comment before releasing the client, and to counteract anyone from premining, I'll probably mine the first block and change the genesis block in the client (as well as the magic number).


I'm altering the original post in the next thirty minutes to simplify some things, and to explain my thoughts on hashes/pseudorandom number generators, as well as future plans with the coin.

Quote
I don't think any of the devs realise what the release of ASICs is going to do.
ASICs are a mixed blessing, they increase and decrease network security, they increase barrier to entry, and threaten the cryptocoin with a 51% attack by a sufficiently wealthy entity. Problem with litecoin is they had specific values for scrypt from the very beginning. Changing it will wreak havoc and encourage secret ASIC mining, unless the plan for changes is a year ahead of time and done in a slow transparent process.

Whatever formulas I make up, they need to be close enough to being adequate or correct now or before market capitalization reaches dogecoin proportions.
Naturally I welcome any help, but I'm not quite sure what I should specifically request.
5  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][MAX] MaxCoin - Alive and Kickin' on: March 21, 2014, 01:34:50 AM
where's the source?
6  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Unnamed Coin on: March 19, 2014, 07:58:54 PM
Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.
1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

Quote
And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.
I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).



How do you suggest that miners agree to reject blocks based on their non-chain-specific content? This would require the manual intervention of "the majority" of miners wouldn't it?

If you need a dev to start looking at it with you I may be able to provide *some* hours. Can't guarantee a huge number as the number of projects I'm working on gets longer every day, but I'm intrigued by the intellectual concept. I'm also interested to explore the idea of developing a coin that ISN'T centred around pumping/dumping. I'm utterly sick of all the liteclones. Almost none of them has innovated anything, and I'm fairly certain the level of saturation is seriously damaging the entire community. I've even heard tell that the saturation may be deliberate in order to damage the market, although I take that with a pinch of tinfoil.

For these reasons, I'm backing Darkcoin as a technological leader, and Cypherfunk as a personal interest project as they both bring something new and interesting to their target demographic, and have both very quickly gained a great following, both of which communities are active, strong and very long-term focussed. If you can achieve the majority of what you've set out in the brief above I can see this coin gaining serious traction.
No, just a majority intervention of a majority of pools.

Problem with Darkcoin is with encrypted block chain... how can you trust it? What if there was a bug, and you can't see someone printing billions of coins? Such an issue happened in the early days of Bitcoin. Bitcoin is founded on the absolute minimum of trust. Minimum of trust of miners, minimum of trust of programmers, etc.

What these liteclones fail to realize is that if you don't use a new method of mining, people with established GPU infrastructure will quickly kill it. You need to change the hashing method to something new to restrict it to CPU mining for the first few weeks.


I welcome any assistance.


Minor note: I'm changing the name of this coin from Unnamed Coin to Nome Coin.


Quote
All the best of luck to topic starter, looks like he isn't a dev but needs one.
Sad
7  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Unnamed Coin on: March 18, 2014, 05:30:25 PM
Also I will add my tuppence: Data storage is a REALLY bad idea, unless you have a method of removing it through some kind of voting mechanism, or it's personal and securely encrypted. To allow unencrypted data in the blockchain is incredibly spammy - the BTC blockchain is already 18GB. Imagine that if there'd been data compressed in it. Perhaps if you ran a second distributed data store or something, and THAT was encrypted, with an opt-out on storing it for people with legal concerns... Although that has its own problems.

The legal ramifications if some sicko spams your blockchain with images of child porn could be huge....

tl;dr: I think storing data in the blockchain is a bad idea.
1. Unfortunately miners can place any sorts of data into the block chain. Satoshi added "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Many following blocks have non-blockchain specific data in the merkle root tree. http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

2. Ideally in a future version, miners can reject blocks manually. The long average mining time should be sufficient time for people to react without an excess of wasted blocks. Also known as discouraged blocks.

Quote
And I like the honesty - "heat death of the universe" :-P I feel like some projects are gonna take that long myself sometimes.
I'll be honest, I have no idea, and it'll take me a while to familiarize myself with the code in order for me to even begin modifying it.
And I doubt there are any programmers interested in cryptocoin development that isn't a pump and dump scheme. If they were truly interested in cryptocoin adoption, then they'd figure out a way to reduce hoarding and induce price stability. Most people aren't young enough to appreciate the possibility of losing half or more of your savings (well, I'm not that old either, but you get my point).

8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Unamed Coin on: March 17, 2014, 11:06:27 AM
Shit man, you need a read a vocabulary, not a new coin.
perhaps

but I don't believe in buying cryptocoins.

I'm just putting forward my two cents as to the ideal cryptocoin.
9  Alternate cryptocurrencies / Announcements (Altcoins) / [ANN] Nome Coin on: March 17, 2014, 10:16:51 AM
changes italicized

ETA: based on my current rate of output, heat death of universe

Proof-of-work algorithm:

The block header is hashed with Keccak[r=1416,c=184] with 8192 bits (1 kibibyte) of output. Using a sequential memory-hard function, the previous hash is hashed again, repeatedly until it is hashed ((1.04^(months past first block))*1.5*difficulty) (rounded down) times. The block headers are then hashed again with Keccak[r=1088,c=512] with 256 bits of output. The previous hash outputs are then collectively hashed using Keccak[r=1344,c=256] with 256 bits of output. In order for the hash to be accepted, it must have an equal or greater number of leading zeroes then the difficulty target.

The intent is simple, to make this ASIC resistant (no one can determine the precise amount of memory needed for an ASIC miner, and thus some chip space will be underutilized), and to be within the cache limits of a CPU to allow mobile devices to still be able to confirm blocks.

Block reward and block difficulty will be retargeted every 660 blocks. The difficulty will target generating a new block every 15 minutes. The block reward will be targeted to equal 200*(difficulty-minimum_difficulty) coins per block.

This is meant to stabilize prices and incentive miners to mine, an increase in economic security (through an increase in liquidity) and an increase in computational security.

Block difficulty is the count of the required number of leading zero bits for a hash. While this decreases precision, it is unlikely for this to matter significantly. It is also unlikely that the distribution of outputs with most pseudorandom functions immune to preimage attacks to be 100% uniformly distributed. This of course means that the average block will be generated between 10 minutes and 22.5 minutes, but averages are a fiction anyway, since it can take between a millisecond and a day for a block to be generated for any cryptocoin.

Block header contains only block number, 8-byte nonce, and merkle root. Version, previous hash, difficulty, timestamp, extranonce, and transactions are located within the merkle root. The difficulty is a one-byte value.

Block fees will be charged per byte of a block, however the first kilobyte for a block is free (the block header and first transaction ought to be free). Block fees will be sent to an invalid address, this is a “fee” that is effectively “collected” by the entire “community” to avoid miners or other entities from causing a tragedy of the commons by spamming the blockchain with either data or dust transactions. It’s conceivable that in the future cryptocoins which round up to the nearest kibibyte will result in people using the spare room in their transactions to upload a book byte by byte. Block fees will be 0.002 coins per byte, although in the beginning block fees are too insignificant to matter. For every additional megabyte, marginal block fees per byte doubles.

The first 67,500 blocks may not be larger than one megabyte to prevent blockchain spam. The first 200,000 blocks may not be larger than two megabytes for the same reason.

Transaction fees will be a means for miners to make profit and to pay off block fees. Transactions fees could be at minimum 0.002 coins per byte.

Smallest coin size will be 0.0001.

Transactions in a future version should include data. It is wrong restricting the ability to add data to the blockchain to miners.

Sanity check for maximum transaction or maximum coins per block is 66000*difficulty.

Terminology will be changed. Wallets for this coin will be “password managers,” and each private key is a “password.” This is more accessible to relative laymen and might prevent certain forms of confusion. It is doubtable an absolute layman will ever be able to truly access a cryptocoin without an online wallet.

The client will ideally include a way to open a bootstrap file, instead of manually navigating through folders and moving files around. The bootstrap file extension should be changed to “.ledger”.


Future plans: Restrict stored transactions per public key to 1 until a block includes the transaction. Delete transactions stored after a week.
10  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: March 05, 2014, 09:22:08 AM
How will the network operate after all Bitcoins are mined?  I have no idea!

we have 20 more years to figure it out - and perhaps only transaction fees will make this possible..

I do start to worry about the time when mining reward become to zero.
I remembered that each block size has limitation of 1 MB .
So the average transaction number per second is about 7.
Total max transaction number of a block is about 7(transaction)x60(sec)x10(min)=4200
We used to decided transaction fee in terms of fiat so no matter what price of a btc is, the fee is always low.
So if the price of each transaction is 0.1 usd, the average total transaction fee of a block is just 4200x0.1=420 usd which is far from current earning.
Where am I wrong?



given the amount of dust transactions, the average transactions per second might be less then one.
11  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: February 28, 2014, 08:58:08 AM
Not sure if you are aware that fees will be 1/10th of what they are now as of version 0.9.
I am aware.

I just think 1/4 is better then 1/10.

It may even encourage bitcoin developers to find ways to reduce the number of bytes checksums and script take up.
12  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: February 28, 2014, 07:59:38 AM
Right now the typical transaction is half a kilobyte or less, correct? And cost is rounded up usually?
Best way to reduce transaction fees is to price it on a per byte basis. There, transactions just got quartered.

how much fees when transfer of bitcoin?  Smiley
right now it's 10k satoshis per kb
what I'm proposing is
10k/1024= 10 satoshis per byte

the typical transaction is a quarter of a kilobyte, so for the typical transaction, it would be reduced by 3/4.
and it would give incentive for more efficient ways of transactions to be made
each byte is very significant since it's going to be stored forever.
and even if people would pay for data to be stored in the block chain, they would have to pay for every byte
13  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: February 27, 2014, 01:39:33 AM
Agree with roslinpl as it's faster and the fee is so small that making it 0 and at the same time making the transactions long lasting is worthless

sure it is like this.

0.0001 is very cheap. and we need to remember that those money are needed to support miners.
I know many people who add higher fee to their transactions.

Just find any cheaper way to send money on planet earth? Smiley (and I am not talking about other cryptocurrencies)

transactions fees per block are 90% of the time... chump change
https://blockchain.info/charts/transaction-fees
https://blockchain.info/
https://blockchain.info/block-index/471229/0000000000000000d162a9c8fcd62c5c90517ca177f44752d9fc74b49912e1b1
Block Subsidy: 25 btc
Transaction fees: .17 btc

.17/25.17 = .68% of miner's revenue is from transaction fees
https://blockchain.info/block-index/471233/0000000000000000b2d9570fa137befb3d6bafbeef7b5e47171f0fc553d8c8d5
Block Subsidy: 25 btc
Transaction fees: 0.07 btc

.07/25.07 = .28% of a miner's revenue is from transaction fees

https://blockchain.info/stats
% earned from transaction fees:   0.32%


transaction fees are too small for anyone to pay attention to


besides

the developers are reducing the transaction fee
I don't know why they don't simply increase precision
14  Economy / Economics / Re: Bitcoin symbol positioning on: February 27, 2014, 01:33:43 AM
very good question
15  Bitcoin / Bitcoin Discussion / Re: Legacy of Mt. Gox on: February 26, 2014, 04:09:27 AM
I think I wouldn't be surprised if the Bitcoin devs face a lawsuit eventually as a result for knowing about the transaction malleability issue for about 3 years and not making a serious effort to address it.

Quote
Copyright (c) 2009-2013 Bitcoin Developers

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

It would be like buying a car "as-is" and then suing because it doesn't meet your needs.  "AS IS" = "AS IS" and is pretty well established in civil law. 
oh yes, it's well established that you can't waive away total liability on if negligence can be proven
16  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: February 26, 2014, 12:06:59 AM
Right now the typical transaction is half a kilobyte or less, correct? And cost is rounded up usually?
Best way to reduce transaction fees is to price it on a per byte basis. There, transactions just got quartered.

You want to reduce 0001 btc fee? :-)
Come on man ... its cheaper than a box of matches ...
 :-)

Why to reduce it?

Anyway you can pay no fee if you like ... qt settings? :-)

If you set the fee to 0, the payment will still reach the other party, it might only take days instead of minutes. correct?
if you set it to zero, you are at the mercy of a generous miner.
17  Bitcoin / Development & Technical Discussion / Re: BOINC, cryptocurrencies on: February 25, 2014, 11:34:47 PM
I am researching a productive proof of work system that uses sha256d.

Imagine being able to do productive hashing at ASIC speeds

Sounds interesting, I'm curious as to how that would be helpful. I mean surely there are better solutions to compute than hashes, isn't it ?
primecoin
18  Bitcoin / Development & Technical Discussion / Re: Better way to reduce transaction fee on: February 25, 2014, 11:20:19 PM
It's true.
But given the recent hubub about developers reducing the default fee, they could easily reduce the fee through increased precision.
19  Bitcoin / Development & Technical Discussion / Better way to reduce transaction fee on: February 25, 2014, 09:58:15 PM
Right now the typical transaction is half a kilobyte or less, correct? And cost is rounded up usually?
Best way to reduce transaction fees is to price it on a per byte basis. There, transactions just got quartered.
20  Bitcoin / Bitcoin Discussion / How many terabytes per year would be created if Bitcoin replaced Western Union? on: January 24, 2014, 10:06:51 AM
How many terabytes per year would be created in the block chain if Bitcoin replaced Western Union?
Pages: [1] 2 3 4 5 6
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!