Bitcoin Forum
September 05, 2015, 07:47:07 AM *
News: New! Latest stable version of Bitcoin Core: 0.11.0 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 164 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: what if a new cryptocurrency had this new feature?!?! on: August 25, 2015, 10:50:33 PM
freicoin
2  Bitcoin / Development & Technical Discussion / Re: How would you prove that you own >= X BTC without disclosing addresses ? (ZKP) on: August 15, 2015, 05:15:21 PM
Using an AOS ring signature only works when you know the pubkeys, which you don't for most coins in the Bitcoin UTXO set.

In any case, the ring signature used to construct the CT range proof is just the AOS scheme when not used with any AND,  so thats implement in secp256k1-zkp.

To avoid the proof size-- you're off in snark land-- e.g. the statement you prove "I know a private key for an adequate coin belonging to a utxo set with this hashroot". I previously suggested a scheme that lets you avoid doing 99% of the EC math inside a snark, so this could get a small under 400 byte proof and be implementable. I think it was in a forum post... I'll have to look. But the basic process have the snark instead prove "Pubkey P is a blinding of a pubkey that is member of this tree", and then you also prove you know P's discrete log externally to the snark. The verification of the blinding can be done with a single point addition in the prover.

A CDS ring signature works just as well, but obviously it would only be functional for currencies like Monero where the pubkeys are published instead of the pubkey hashes.
3  Bitcoin / Development & Technical Discussion / Re: Different signatures for the same transaction. on: July 05, 2015, 04:32:42 PM
I believe core version 0.10.0+ uses deterministic k-value generation following the guidelines in RFC6979. The code for this is in the newly used libsecp256k1.

It you want to make random k-values, rollback to a version using openssl, or write your own code.

Note that if you generate R-values or S-values that are too high, the network will or may reject them (as detailed in BIP0062).
4  Bitcoin / Development & Technical Discussion / Re: BIP-47: Reusable payment codes on: June 23, 2015, 03:01:53 AM
I would rather we stick to the stealth address format that exists and finalize it instead of switching to another construction stealth addressing, when it's being used in essentially the same way.

Stealth addressing works OK as is, however we can transmit the extra data from that would normally be disclosed in an OP_RETURN out-of-band via an intermediary like Bitmessage. Essentially this appears to be your described protocol, and I think it'd be preferred if we worked within the established protocol as an extension of the proposed BIP0063, and backwards compatible with the described address format.

Additionally, solicitation (Notification Transaction) should be done out-of-band, rather that by the use of the blockchain and OP_RETURN tagging. I think it's potentially wasteful, aside from being permanently embedded in the blockchain and by which causing a loss of privacy. A proper out-of-band solution for stealth transacting should never need to resort to blockchain access, as far as I am concerned.
5  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: June 18, 2015, 02:16:50 AM
Exchange.I2P Darknet CryptoCurrency Exchange : https://bitcointalk.org/index.php?topic=1092682

According to this Monero isnt going to be listed. At least at the start.

His reasoning can be found below. Perhaps one of the XMR core devs can inquire further and find a solution:

"The issue with cryptonote coins is that the server must run a node anonymously. Bitcoin based altcoins can be run over tor, monero etc cannot. This increases the risk of demasking."

https://bitcointalk.org/index.php?topic=227287.msg11646812#msg11646812

Run your node inside whonix or another torified VM

https://www.reddit.com/r/Monero/comments/31ciuf/questions_running_monero_over_whonix/

If you don't have the technical expertise to set this up, I'd question whether you should be running a "dark" exchange at all..
6  Alternate cryptocurrencies / Altcoin Discussion / Re: is Bytecoin a bitcoin clone? on: June 11, 2015, 04:23:44 PM
There are two Bytecoins, one is a Bitcoin clone, the other is an entirely different codebase, elliptical curve, difficulty algorithm, etc
7  Bitcoin / Bitcoin Discussion / Re: A lot of users dislike altcoins but are pro sidechains, why? on: June 11, 2015, 04:21:47 PM
I can't wait for the multitude of sidechain forks that all compete with each other. Sidechains themselves require incentives to operate securely, such as fees and the continued security of the Bitcoin network, so I'd guess we'll start to see a lot of the same issues in sidechain space as we do in altchain space. I really don't think there's any difference between the two. You can also issue your own assets already on Bitcoin (e.g. coinprism, counterparty), so the notion of token issuance for use in general scamming will surely appear on sidechains as well. You can't out-technology human speculation in finance.

There is no speculation incentive because all investments are denominated in BTC. Thus this will force consolidation. Unless there are revenue models and/or dividends for side chains.

Ah... just like all alt coins are merge mined with Bitcoin to support the entire network hash rate? After Elements adds explicit tokenization it'll be easy for anyone to make a sidechain fork and issue "Sidechain Funbux" on their fork, pre-sale them, etc. Bilateral two-way peg also means that Bitcoin might inadvertently end up supporting a number of pre-existing alt. coins anyway; especially since we can now explicitly tokenize them in a 1:1 peg on the elements sidechain and transfer them there.

You can change the tech, but you can't change the underlying issue.
8  Alternate cryptocurrencies / Altcoin Discussion / Re: Understanding Stealth Addresses/Payments on: June 10, 2015, 07:57:46 PM
Now that I think about it, it seems to me there is another way to achieve the same thing. Since the payee needs to share his full public key (Q), it would be possible for the payer to encrypt data using Q and only the payee would be able to decrypt it. The payer can generate a random number (r), then use that in the same way as the shared secret to generate Q'. Then they encrypt r using Q and embed it as metadata. The payee can scan for transactions by checking if his private key can decrypt the metadata.

EDIT: or better yet, the shared secret is generated the normal way by multiplying the private and public keys together, but we use it as the key for a strong symmetric encryption algorithm to encrypt r instead of using Q to encrypt r, which should be a more secure approach.

There is no orthologous method for ECDSA that you'd use to directly encrypt data to a recipient key as you would with RSA. ECDSA is purely for signing.

What you're describing (using the shared secret for a symmetric cipher) is known widely as Elliptic curve Diffie–Hellman (ECDH). It overcomes the above limitation. It is used to transmit messages in transactions in some CryptoNote coins, and is widely used in protocols such as SSH and TLS.

http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman
9  Alternate cryptocurrencies / Altcoin Discussion / Re: Understanding Stealth Addresses/Payments on: June 10, 2015, 06:05:11 PM
Please refer to CryptoNote CNS006 for an explanation

https://cryptonote.org/cns/cns006.txt

Please note that stealth addresses do not afford anonymity but rather forward privacy (they obfuscate where funds are being sent to). Recipients also must scan the blockchain to decipher if any outputs belong to them (and so thin clients become a bit more difficult, because they can no longer simply poll a server for an address balance).
10  Bitcoin / Bitcoin Discussion / Re: A lot of users dislike altcoins but are pro sidechains, why? on: June 09, 2015, 08:37:21 PM
Because you still keep using bitcoin and its snet effect it is spread around the people in the world

you don't need to accept a bunch of altcoins,just accept bitcoin
Pretty much this. Altcoins are just a hindrance, people are creating them as pump and dump in order to earn quick money almost in 100% cases.
Most of them are copy paste or existing code without any changes beside name of the coin. Instead on focusing our attention on altcoins why don't we focus and upgrade bitcoin?
It would beneficial for us a lot more than creating new altcoin everyday. I think going pro sidechains are also not the way to evolve... Only pure bitcoin is the way. Stop deviations.

Perhaps in the Soviet Union of Bitcoin. Economic outcomes are terrible when there are no competitors for any given market, for example, if there were a government monopoly allowing only a single car manufacturer. You might imagine that this single company would have the highest efficiency, but the reality is that efficiency actually decreases without competition. I doubt Blockstream and sidechains would ever have come into being without the pressure (and sometimes, innovation) afforded by altchains.
11  Bitcoin / Bitcoin Discussion / Re: A lot of users dislike altcoins but are pro sidechains, why? on: June 09, 2015, 08:30:18 PM
Sidechains are altcoins, which use Bitcoins as their basis. By subscribing to the sidechain, you subscribe to the same ethos as Bitcoin... namely, the vast number of coins owned by Satoshi and now the core developers (some of whom were rumoured or seen to have made large purchases of Bitcoins with the formation of Blockstream).

I can't wait for the multitude of sidechain forks that all compete with each other. Sidechains themselves require incentives to operate securely, such as fees and the continued security of the Bitcoin network, so I'd guess we'll start to see a lot of the same issues in sidechain space as we do in altchain space. I really don't think there's any difference between the two. You can also issue your own assets already on Bitcoin (e.g. coinprism, counterparty), so the notion of token issuance for use in general scamming will surely appear on sidechains as well. You can't out-technology human speculation in finance.

The other issue with sidechains is that effectively everything can become a sidechain of anything else if you push foreign coins onto Bitcoin mainnet as coloured tokens. I've been calling this "bilateral two-way peg" for a while, and I'm not sure that there's any way Bitcoin mainnet could prohibit it after they add sidechain-related OP codes. The real (negative or positive) value of sidechains remains to be seen, and I think we haven't even touched the scale of redundancy that might occur in the future as a result of them.

The good thing is that the Blockstream guys are doing some pretty neat cryptographic research, in any case.
12  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 09, 2015, 04:56:28 PM
Furthermore, if the reward is (1 - penalty) * (minted coins) + tx fees, then in the future when the minted coins go down to 0, there is no penalty at all. That's the opposite of future-proof.

Monero is permanently inflationary, so there will always be an impact of the penalty.
13  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 09, 2015, 04:14:15 PM
Well, I'm impressed. Why you went to the trouble to implement your ring signature scheme makes a lot more sense now.
14  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 08, 2015, 10:47:24 PM
Quote
Thanks for that, it was my reading also.
Thus TX fees that are not in the block but paid out of band are not subject to penalty...
It's an additive deduction, not multiplicative.

You seem to be thinking the miner's reward is:
(1 - penalty) * (minted coins + tx fees + collection from pool)
Where it is really:
minted coins + tx fees + collection from pool - penalty

Having more fees in the txs included doesn't increase the penalty. There is no difference between adding 1 mBTC to the fee and paying 1 mBTC out-of-band.

I don't see how this differs from in Monero?

In Monero, addition of txs up to the median blocksize is free. As you surpass the median blocksize, a quadratic penalty is applied to the subsidy of the coinbase, but amounts obtained from tx fees are untouched. The subsidy of the coinbase is initially dependent of the number of coins in existence, and so takes into account the previous penalties to coinbases of any previously generated blocks (comparable to your "pool" method). Then, the miner is free to add transactions meeting some economic equilibrium that maximizes their overall income when taking into account the blocksize penalty to the coinbase subsidy.

So, it's like this:
(1 - penalty) * (minted coins) + tx fees
where penalty is dependent on the size of the block above the median size according to the formulas found in the CN whitepaper.

gmaxwell criticizes this as promoting out-of-band transactions, but the fact remains that to permanently and secure transfer money you must use the blockchain and have it included in a block somewhere. Thus, I never thought it was much of an issue.
15  Bitcoin / Development & Technical Discussion / Re: Elastic block cap with rollover penalties on: June 03, 2015, 03:09:57 AM
Isn't it precisely what is implemented in Monero? (except you don't have a rollover pool, the penalty is simply deducted from the block reward for good).
No idea what happens in Monero, but if so, more power to them.

Yes. There is a quadratic penalty imposed for blocks above the median size (with a maximum size of 2 * median(size of last 400 blocks)), with a dynamic, elastic block sizing algorithm. Unlike Meni's suggestion, the reduction in block subsidy is not given to a pool but rather deferred to future miners because the subsidy algorithm is based around the number of coins.

See section 6.2.3 of the CryptoNote whitepaper: https://cryptonote.org/whitepaper.pdf

It was one of the most criticized components by the Bitcoin core developers, but so far testing on the mainnet and testnet has failed to evidence any failures.

There is a major shortcoming I can see in the rollover fee pool suggestion: miners are incentivized to accept fees out of band so they can obtain all the highest fees instantly, thus defeating the entire purpose of that feature.
16  Bitcoin / Bitcoin Discussion / Re: Wrap It Up, bitcoin Is Done on: April 29, 2015, 05:44:46 PM
https://bitcointalk.org/index.php?topic=924967.0
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: April 28, 2015, 08:16:20 PM
itt people attempt to make sense of speculators because occam's razor of "playing a game of financial chicken and trying to pump and then dump in sync with everyone else" isn't illuminati enough
18  Bitcoin / Development & Technical Discussion / Re: NuDB: A Key/Value Store For Decentralized Systems on: April 11, 2015, 10:52:47 PM
These types of DBs are popular lately, for example, btcwallet now uses boltdb, while Monero uses LMDB. They're all kind of similar: full ACID semantics w/ MVCC, data stored on disk in B+ trees, async read/update with scheduling and transitory state patches for reads, multiple namespaces, nested buckets, etc.

AFAIK, bitcore is moving towards adopting more DB agnostic architecture, so in the future you can plug and play whatever crazy DB type you want.
19  Bitcoin / Development & Technical Discussion / Re: Is there a payment protocol that can include a physical address? on: April 09, 2015, 09:30:01 PM
You can use stealth addresses to send the payment to a specific vendor with a stealth address, providing the extra data to recover the private key on a separate channel e.g. email. You can encrypt information like post address to the recipient using the ECDH shared secret and a symmetric key cipher.

So basically, the receiver posts
[recipient_email_address]&[stealth_address]

Sender sends this information to the receiver's e-mail address:
[shared_secret] (for encryption and recovery of private key)

then this other encrypted information in the e-mail:
[requested_items]
[txid_for_payment]
[where_to_ship_to]

Sender uses the derived pubkeyhash as an address and sends their funds there on BTC mainnet, receiver gets e-mail, decrypts all relevant information, recovers privkey for the address yet sent to.

I've been meaning to implement this (and indeed I've started a bit), but I've had other things to work on lately.
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - A secure, private, untraceable cryptocurrency - 0.8.8.6 on: April 07, 2015, 06:58:47 PM
David is core development team, but he's not really a programmer. He tends to handle PR and the like.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 164 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!