Bitcoin Forum
May 28, 2024, 04:40:17 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 »
121  Bitcoin / Development & Technical Discussion / Re: Why does Bitcoin not implement anon? on: July 18, 2014, 03:56:32 PM
Coinjoin/similar schemes is supported by the protocol. I believe dark wallet and in the future others will have it enabled as default out of the box.

A research paper on coindesk recently stated that even with NO masking efforts they could only trace 10% of transactions by looking at the blockchain.

http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html

10% is wrong if you're talking about tracing 10% of transactions to output accounts like Coinbase, where the user sells his BTC for USD, it's much much higher, if you're talking about tracing regular Bitcoin transactions, it's 100%. Also coinjoin is deplorable, even having the slightest taint during mixing can reveal your tracks..Darkwallet is also centralized and being such, if it were to get hacked or anything like that, your funds could be stolen like any other malicious wallets out there..
Researchers were only looking at the blockchain.

Of course governments/exchanges would have more information as you say.

I don't know the details about darkwallet, better things will always come in the future given time.

Coinjoin/similar being deplorable.. I don't know about that, it can be done in a decentralized manor and if done correctly with enough sources and mixed enough times I think even the NSA would have only random guesses to go by.
122  Bitcoin / Development & Technical Discussion / Re: Why does Bitcoin not implement anon? on: July 18, 2014, 03:28:13 PM
Coinjoin/similar schemes is supported by the protocol. I believe dark wallet and in the future others will have it enabled as default out of the box.

A research paper on coindesk recently stated that even with NO masking efforts they could only trace 10% of transactions by looking at the blockchain.
123  Bitcoin / Development & Technical Discussion / Re: Very very simple yet powerful 51% solution on: July 18, 2014, 03:16:07 PM
What happens if some clients have a trust-list different than some other clients? There will be two separate and incompatible blockchains then, right?
Yes and no.

This concern is why my solution would have two different "punish modes":
1. At ~40% of blocks untrusted the client will just not relay another untrusted block for 1 hour.
So longest chain is in this case still accepted even if it is 90% untrusted. However propagation would be slower for the untrusted pools in this case.
2. Outright rejection that you mention. It would ONLY happen if something like ~99% of the last ~100 blocks are untrusted.

So the hardfork situation you describe could happen, but ONLY if the majority of nodes A Do not have ANY trust overlap and B 99% of blocks are untrusted by both partition 1 and 2 clients using your own example.

Mode 1 makes centralization harder and mode 2 prevents a total denial of service by a single player preventing all transactions.
124  Bitcoin / Development & Technical Discussion / Re: Very very simple yet powerful 51% solution on: July 18, 2014, 08:11:31 AM
Anyone can mine even with no ID in my system - that includes sole mining.

So... if a miner had 51% of the network, couldn't a "bad" mining pool simply set the ID on half of their miners to be "no ID" - so then it would look like they only controlled 25% of the network... when in fact, they would control over 50%.

Which would be effectively the same as the current situation where GHash publicly controls 40% of hashrate - and I've read claims (not saying true or false, just that some people claim) they also control another 10-15% of "unknown" miners.

Sorry if I've misunderstood.
No, because if they are removed from the trust lists then their blocks and all other untrusted / no ID blocks would be counted as one partition w. +50% and these new clients would start to not relay their blocks.

You can still do some double spend attacks in my solution, but there is an upper limit introduced and total control becomes impossible.
125  Bitcoin / Development & Technical Discussion / Re: Very very simple yet powerful 51% solution on: July 18, 2014, 07:08:23 AM
Coinbase coins are not the same as gmaxwell stated.
You said "3. A pool would send some BTC from the coinbase to TRUST_ADDRESS.
4. In the SAME block the pool sends from TRUST_ADDRESS to where-ever."

They can't be "spent" for 100 blocks as was stated to do so would require a protocol change.

Very well this is not critical. There are a multitude of ways to put data such as a signature in the blocks:
1. Coinbase transactions allow arbitrary data in their script.
2. OP_RETURN (experimental though)

I have edited my post to use coinbase data instead.

Quote from: kolinko
Actually, he's correct. It's you who should reread what you wrote. Seriously.
See above.

I apologize for my tone, I thought he had skimmed my post.

Quote from: gmaxwell
If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) ...
1. I will not.
2. No state license, JUST a cryptographic signature that "TRUST_ADDRESS"-owner created this block - who-ever he is.

Quote
... but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership)
1. Yes anonymity is important. That is why no membership is required and its just a signature the pool makes.
2. You can STILL mine with my solution as untrusted. My idea would ONLY really do something if all the blocks came from a single trusted party or from various unknown/untrusted sources.
3. It is not a proof of trust, but just proof a certain perhaps anonymous source made the block and you only care in extreme cases.

Quote
Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.
1. Since it is only a cryptographic signature you don't know WHO it is. It could be a botnet that no one knows anything about but they just happen to make fairly normal blocks
so they get added to the trust list.
2. Miners can still mine whatever they like, this makes no change to that at all. You can still make 100% empty blocks. Only if it becomes an issue people will remove you from the trust list.

Quote
(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)
Ok so we put a signature of the block or block height into the coinbase script or somewhere else.

Quote
If anyone can mine with no ID and no disadvantage what prevents every miner (including the attacker) from using a unique ID in every single block, and thus being indistinguishable?
1. The ones adding the IDs to trust lists would be users and client developers. Random new IDs would not be in the lists. Yet there is no central authority.
2.  However if 50-60% of the network is mining with known and trusted IDs then it doesnt matter if a new pool or "attacker" makes blocks with unknown IDs/no IDs they will still be accepted.

Quote
Alternatively, if you pin blocks based on the decisions of some of these "optional" IDs to the detriment of IDless miners, what prevents the ID-ed miners from pinning a particular otherwise-non-consensus blockchain

1. You still have to follow protocol, it would be impossible to change rules.
2. There is ONLY detriment to ID less miners if they combined make 40% + of all blocks otherwise all are equal.
3. Again users choose which IDs their client should trust so who is ID-ed/trusted miners can change instantly during an attack.
126  Bitcoin / Development & Technical Discussion / Re: Very very simple yet powerful 51% solution on: July 17, 2014, 10:15:00 PM
If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) you might as well eliminate the mining, use signatures, and call it SWIFT.

There are perfectly legitimate uses for signature based systems— they have useful security/performance tradeoffs— but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership) as part of the process of making it decenteralized and somewhat censorship resistant.

Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.
You are 100% incorrect you need to go up and read my post again.

I propose nothing close to what you are describing.
Anyone can mine even with no ID in my system - that includes sole mining. You have quite simply misunderstood like all of it.

Quote
(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)
I'm confused, I'm pretty sure coinbase coins are the same as other coins and I propose no change to that.. plz read before posting/voting.
127  Bitcoin / Development & Technical Discussion / Re: Very very simple yet powerful 51% solution on: July 17, 2014, 09:50:38 PM
2. Let individual full nodes add or remove pool IDs to/from a "trust list".

What's to prevent an attacker from running a full node that has them added to their "trust list"?
Nothing.
Same way I can create a node where I have all 21 million coins.

It's a question of consensus, if the majority of Bitcoiners want a decentrallized Bitcoin during an attack that BECOMES the real Bitcoin.

Quote
This could mean the entire network could prevent a pool from getting blocks just because they don't like them, unless we assume these protocols only come into place if the block finder has 51% of the network hashrate?
Pools are not blocked. Its just their blocks that will not be accepted if they make all the blocks.

Its not a blacklist.

The reason it is okay to have "untrusted" blocks in the chain is that you don't care as long as you don't have frequent rollbacks and your transaction goes through.

This is why this solution ONLY cares if ALL the blocks are from an untrusted source.
128  Bitcoin / Development & Technical Discussion / Very very simple yet powerful 51% solution on: July 17, 2014, 09:40:34 PM
Hi.

I am the "technical speaker" for the Danish Bitcoin Foundation. I am also currently programming my own project directly interfacing with the Bitcoin protocol.

This is my proposed solution to 51% attacks, centralization issues, selfish mining and any such. This simple solution takes care of them all.
Someone could do this very quickly and I am willing to personally pledge 2000$ towards it.

The reason I don't do it is that I'm already swamped with two "public good" Bitcoin projects, a full time job and a family.

Layman's terms
1. Establish a way mining pools can document they made a block - pool IDs.
2. Let individual full nodes add or remove pool IDs to/from a "trust list".
3. A full node will not relay untrusted/unknown blocks  for ~1 hour IF 40% of the past 100 blocks were from unknown/untrusted pool IDs/ +50% from one single trusted ID.
4. A full node will not accept blocks if 99% of past 100 blocks were from unknown/untrusted pool IDs.
(exact percentages do not matter that much)

What it will do
Basically as the network is now it wouldn't do anything. Everything would be fine.

Once ~10% of full nodes upgrade miners would have an incentive to ID their blocks - simply for faster block propagation.

IF the network however came under attack such as:
A Many targeted double spends by a corrupt pool.
B Selfish mining escalation.
C No transactions in blocks.

THEN the solution would elegantly force the attacker to include at least some few blocks that could not be rolled back by the attacker and that contained transactions.
If the attacker DID not allow for other's blocks the attackers blocks would simply be ignored.

Once a "trusted" block was found the attacker can work on that and again make 99 blocks, so this is NOT a white/black list solution.

Ok so there's a catch right? It's a hard fork? Slow? Bullshit extra chains? Exotic crypto? Tatiana coin infusion? (no offense Tatiana)
No, none of the above.
There are literally ZERO drawbacks.

Technical detail
1. The protocol allows for a coinbase transaction script to have arbitrary data.
2. We can use this to let pools sign blocks with an "ID".
3. A pool would sign say the hashes of non coinbase transactions with their ID (w. SECP256k1).
4. Put the signature bytes in the coinbase transaction script.
5. This should be easy to put and read in blocks.
6. Only the pool has the PRIVATE_ID_KEY and the contents of the block are now signed.
7. The ID_PUBKEY can then be used as an ID.
8. No changes in protocol, zip, nada. Just an optional check for certain data.
9. Add the largest 20 pools to the trust list and no one ever has to talk about 51% again.
10. Its totally organic too, anyone can start a new pool and create an ID for themselves. Even botnets are still in, they just can't take over.

What it would really do:
Skeptic: I heard Bitcoin is under attack and will die?
You: Naw that can't happen because miners would then kill the coin and then... bla bla bla incentives... maybe ... bla bla bla and besides tree chains could fix it.... bla bla.
Skeptic: Huh?

--> To this -->

Skeptic: I heard Bitcoin is under attack and will die?
You: Nodes would reject that and kill it because all blocks would come from like the same dude.
Skeptic: Ah ok... is it still a ponzi though?
129  Bitcoin / Development & Technical Discussion / Re: How to add arbitrary 40 byte data per transaction. on: July 15, 2014, 06:44:30 AM
Won't the sent amount just all go towards miners fees or is the "correct way" of putting data really to create unspendable dust?
130  Bitcoin / Development & Technical Discussion / Re: Technical details on claim script/signatures - Help Please on: April 26, 2014, 01:51:37 PM
Thank you to all of you for helping me out and special thanks to Etotheipi for making some of the documentation in the first place.
I found that the BouncyCastle library should be able to do DER encoding.

I'm still not entirely sure how the claim script is structured and encoded though.
131  Bitcoin / Development & Technical Discussion / Technical details on claim script/signatures - Help Please on: April 18, 2014, 02:26:31 PM
I have poured over the available information I could find such as:

https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
https://en.bitcoin.it/wiki/Protocol_specification#Signatures
https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash

Aswell as mathematical descriptions of how ESDSA works:
http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/

However I have some questions I hope someone knows a resource for or the answer to:
1. In the linked picture what is "script part 4"?
2. Is it correct that script part 1 is R and S concatenated and compressed with DER encoding?
3. Is script part 2 the pub key?
4. If yes, is the  pubkey also DER encoded?
5. Where is the implied script part 3?
6. Can OP_CODESEPARATOR be left out entirely without invalidating the script?
7. Basically what is the byte-wise format of the claim script, this is my own educated guess:
START: DER(RS){approx. 70 bytes} VARINT_PUBKEY_LENGTH pubkeybytes{32 bytes, x coordinate of Qa} :END

(The out script would not be repeated when claiming, but is seen here:
OP_DUP OP_HASH160 VARINT_PUSH_BYTES PUSHEDBYTES{hash160 of Qa/address} OP_EQUALVERIFY OP_CHECKSIG )


A good exact and in-depth explanation of DER encoding would also be nice.
132  Bitcoin / Bitcoin Discussion / Re: I bet that this it NOT Satoshi Nakamoto on: March 06, 2014, 07:57:37 PM
The criteria "fits unknown age, is programmer, is smart, writes english and is reclusive" fits an awful lot of people in this world. (Hal Finney thought Satoshi was young btw.)

We know that the real Satoshi reset the timestamps on his communication to +0 GMT as well as other things to stay hidden - why would such a person use his real name? Even a real name not used in 40 years would still be easily-ish trackable.

This is speculation of my own, but I can't help thinking that the real Satoshi is called something that has nothing to do with "Satoshi Nakamoto".

I know even a genius is not infallible, but his OWN name while trying to stay hidden? Why? Might as well move the Satoshi coins straight to a passport verified exchange account and check out to his personal bank account!

I'll believe it when the name is "Bob Hansen"/"Cheng Hui" and was found via the email/github trail and mail server/NSA records and the person in question is caught with some incriminating evidence - such as known Satoshi private keys.
133  Bitcoin / Press / Re: [2014-03-04] MtGox Issues New Statement, Blames Software Bug on: March 05, 2014, 06:29:58 PM
It is a bug... An exploit exploits bugs in software... Glitches, bad programming, poor execution... (Bug = undesired operation.)

He just stopped claiming ownership of the bug/flaw. Tongue

Termed because it "bugs you"... (Bug, bother, annoy, haunt)

I believe that is a political play on words.
Actually old old computers frequently broke because of actual living bugs crawling inside and messing with the radio tubes.

Or so I heard.
134  Bitcoin / Development & Technical Discussion / Re: How would incorrect number of decimals be handled? on: March 05, 2014, 04:48:34 PM
Amounts in transactions are integer numbers of satoshis. It is impossible to represent 0.5 or 0.1 satoshi.

Onkel Paul
Hmm yes you have a point, even if it changed and my device could be told I would have to guess the exact format used in the future 10-20 years in advance.

(Say we keep it as integer but 0 becomes = 0.001 satohis (since few will have even 1 btc by then)
OR we switch to some non-int format like string... impossible to know)
135  Bitcoin / Development & Technical Discussion / Re: A rolling root to solve Bitcoin's scalability problem? on: March 05, 2014, 04:17:29 PM
This was debated before, what you call  "rolling root" we called "ledger-solution"/"ledger-block".

Same idea; every say 1 year you would take all the 20 years or older transactions and move their unspent outputs to the latest "ledger block". Amounts in the ledger block would be much like coinbase transactions/miners fees.
Barring minor minor data growth from address fragmentation and perhaps block headers, this puts a quite final limit to the blockchain size.

Another idea (of my own) was "swarm clients" that individually would validate only parts of the blockchain, but as a whole would validate the whole thing - all zero trust etc..
This would allow for almost the smallest devices to participate in block validation forever.

You can google these terms, and I do mean google, the forum search is shite.

The main reason nothing has happened yet is laziness and people too busy getting rich off of Bitcoin - and no you can't lump me in with that group I have been hard at work helping Bitcoin for a while now.
136  Bitcoin / Development & Technical Discussion / How would incorrect number of decimals be handled? on: March 05, 2014, 03:59:59 PM
What I mean exactly is that right now Bitcoin has 8 decimals going from 1 bitcoins to 1 satoshis or 0.000 0001 bitcoins.

In the future especially, for nano-payments between automatic software using payment tunnels, we will likely add more decimals.

My question is: If a client or device made a mistake today and say sent 0.1 satoshis (assuming this was NOT treated as dust/ignored) which would happen:
(or more realistic maybe: 1.000 0000 1 btc)

1. TX is invalid and simply ignored/could NEVER be in a valid block?
2. TX is valid, amount below satoshis/"rounding error" becomes a miners fee?
3. Amount is lost, goes through as a 0 btc TX (or 1.000 0000 in realistic example).
4. Something else?

Thanks in advance.

Why:
I'm programming a device, similar to say a Trezor, that cannot be reprogrammed later and cannot access the internet on its own.
The device could trust information about decimal places from an untrusted source, but I am just wondering if this could backfire.
137  Economy / Service Discussion / Re: Anyone who had btc on gox since 2011 could be affected on: February 27, 2014, 09:29:15 PM
This is why I'm encrypting my stash, sooner or later, with whatever excuse the cops will knock down my door.

By then I intend to not be there or at the very least have the pleasure of laughing in their stupid faces.
138  Bitcoin / Development & Technical Discussion / Re: How Do I Find a Qualified Programmer on: February 02, 2014, 10:48:35 AM
We're looking into 200k+ investment at 3QT, most of it spent on the marketing side of the project. Will be followed up by bigger numbers. Just need to bring up a physical concept with minimal cost as a beginning. Probably just the ATM and wallet app at this point.
These technologies already exist, if you have 300K to blow on marketing then:
1. License an app, stick your logo on it.
2. Buy robocoin machines or whatever.
3. Do the marketing.
139  Bitcoin / Bitcoin Discussion / Re: Bitcoin Users Can Face Jail Time up to 15 years on: January 30, 2014, 07:33:49 PM
It's coming; banks and governments are starting to understand and they will regulate harshly, then persecute us all when it fails...
140  Bitcoin / Bitcoin Discussion / Re: 90 BTC stolen! on: January 26, 2014, 10:37:46 AM
Maybe bad random generator in QT strikes again?
Again?
Android qt relied blindly on the java "secure" random function and money was lost. Maybe something similar happened here.
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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!