Bitcoin Forum
June 18, 2021, 12:01:37 AM *
News: Latest Bitcoin Core release: 0.21.1 [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 42 43 44 45 46 47 48 49 50 51 ... 62 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] TIERION [TNT]Token Sale Starts on 27 July on: August 16, 2017, 12:50:40 AM
The Misleading and Inaccurate Claims Made to Tierion ICO Investors

https://petertodd.org/2017/misleading-and-inaccurate-tierion-ico-claims
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] TIERION [TNT]Token Sale Starts on 27 July on: July 28, 2017, 01:30:44 AM
I wrote up some things that you should know about the Tierion ICO:

https://petertodd.org/2017/what-you-need-to-know-about-the-tierion-chainpoint-ico
3  Bitcoin / Bitcoin Discussion / Re: Has Julian Assange met Satoshi Nakamato? on: January 18, 2017, 02:14:38 PM
For the record, I said that *I* met Assange, not Satoshi.

And there's nothing terribly interesting about that: he wanted to know more about Bitcoin, and someone who's a friend of a friend suggested we chat next time I was in London; I'm always happy to talk about Bitcoin to people.
4  Bitcoin / Development & Technical Discussion / Re: Blocksonly mode BW savings, the limits of efficient block xfer, and better relay on: February 26, 2016, 04:09:30 AM
Would these IBLT tx relay techniques also help defeat traffic analysis? Seems to me that they might, which would improve privacy against attackers like the NSA.
5  Bitcoin / Development & Technical Discussion / Re: Why all blocksize propositions are round numbers ? on: January 23, 2016, 09:33:26 PM
Because they're not based on science.
6  Alternate cryptocurrencies / Altcoin Discussion / Re: Poll: Should we rename the alt section the Peter Todd section? on: July 21, 2015, 10:32:23 PM
I heard he woke up today, ate a sandwich and scratched his belly.

FALSE.
7  Bitcoin / Bitcoin Discussion / Re: Freezing BitCoin addresses by regulating miners on: June 14, 2015, 02:09:34 PM
FWIW I've run into a lot of regulatory people who have pretty clear views that Bitcoin mining should be regulated such that addresses are blacklisted or even whitelisted. Obviously that's a goal, not necessarily what they'll succeed in making happen, but that's what the long-term intent is. For instance, one regulator I talked to a few months ago at a conference was *very* clear in her view that the Bitcoin protocol simply must be changed to add verified digital identities to the protocol itself, and mining blocks with transactions without valid identities and/or extending blockchains with non-compliant transactions should be an illegal activity that's prosecuted.
8  Bitcoin / Development & Technical Discussion / Re: Bitcoin GPLed because of GMP? on: June 14, 2015, 02:03:59 PM
https://gmplib.org/

"Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2. These licenses make the library free to use, share, and improve, and allow you to pass on the result."

What version of GMP does it need?
9  Bitcoin / Bitcoin Discussion / Re: Freezing BitCoin addresses by regulating miners on: June 14, 2015, 12:24:46 AM
Yo, Pete:

Who's the guy who is making a credible threat to subsume Bitcoin under his personal project and is for all intents and purposes the acting 'benevolent dictator' of Bitcoin at this point?  Oh right...Mike Hearn.  Who could have predicted that and assigned status as appropriate???

Credible? We'll see. Smiley

Re: benevolent dictator, nah, we don't have one of those - maybe Wladimir.
10  Bitcoin / Development & Technical Discussion / Re: Will the Stealth BIP (Bitcoin Improvement Proposal) ever be done? on: June 09, 2015, 02:15:53 AM
Long story short, right now I think my time is better spent focusing on more fundemental issues with Bitcoin like scalability.

I've also got no-one interested in funding stealth address development right now; I do need to pay rent!
11  Bitcoin / Development & Technical Discussion / Re: BIP 66 status (miners' votes) on: May 19, 2015, 03:10:38 AM
I guess a pool must have upgraded. 

yep, it's AntPool

It's my buddies at FinalHash.
12  Bitcoin / Bitcoin Discussion / Re: Gavin is an Agent on: May 05, 2015, 08:27:49 AM


Take a look at this picture of Peter Todd, look at his T-Shirt and tell me he's being ironical. You don't wear a T-Shirt with NSA logo unless you idolize them or work for them.

I remember the first time I met Peter Todd, Jeff Garzik introduced him to me, he just seemed to pop out from nowhere. My encounter with him was brief. But I noticed he didn't swallow the bait even then. So I don't really know his real motive being in the Bitcoin game.

lolololololol

I got that shirt from the Electronic Freedom Foundation's booth at 31c3: https://www.eff.org/deeplinks/2013/06/back-popular-demand-nsa-spying-t-shirts-members

Sadly the NSA isn't sufficiently self-aware to sell shirts saying "ALL YOUR DATA" with glowering, red-eyed eagle's... but they should be.

And for the record, I'm a Canadian - I work for CSIS, not the NSA.
13  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 09:17:45 AM
Bitcoin is a consensus protocol to determine the validity of some binary data. Fundamentally, it is just a language. It could not be regulated like regulating a company because there is no one to send to jail and nothing to confiscate. The only way to regulate bitcoin is to control >50% of the hashing power (or to regulate bitcoin users, but bitcoin users != bitcoin).

Quite simply, there'a a high chance this will be the crypto wars all over again. Like the first iteration of the crypto wars, it's a winnable battle, but it is a battle we can lose too.

In any case, regulating Bitcoin by controling >50% of the hashing power is perfectly possible. At minimum there's always the nuclear option of telling the (very few!) chip fabs of the world to add kill switches to the ASICs they make and/or regulate who can buy them.
14  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 08:35:02 AM
There is no reason to store these kind of private encrypted data on the blockchain. The blockchain should be used for storing

  • Public data, or
  • Private data but timestamping is needed

For the case you suggest, users and merchants should digitally sign those receipts and KYC data (with mutually agreed timestamp if needed) and keep it by themselves.

I've actually had this discussion with regulatory/banking types... There's pressure to have the data on the blockchain itself precisely because it forces it to be "sufficiently" public for governments to be happy - many of them want it to be fundamentally impossible to use the blockchain without giving up that information. First step is to be able to know for sure if the data exists.

Obviously pay-to-contract-hash techniques are the sane way to do this stuff... but we don't necessarily have the same goals as regulators do. One of the hard political challenges for people enganging with regulators is convincing them that privacy matters, and any KYC system has to be an add-on, not an inherent part of the system.
15  Bitcoin / Development & Technical Discussion / Re: Proposal for some BIP with KYC elements on: April 25, 2015, 05:47:55 AM
Interfaces for regulation must begin to develop, this is nothing about hurting the Bitcoin user's privacy, we need to break away from that "drug dealer "character and understand that protocol-level standards will create strong ground for that Nobel technology.

Government/bank signed and controlled blockchains are already being worked on that implement all the identity tech you're looking into and more - I've even been told about requirements for these projects to have every single invoice to be uploaded to the blockchain so the government can investigate not only who sent money to whome, but what exactly they were buying. Of course, this is nothing new: credit card processing platforms are already starting to do this stuff too with bigger merchants.

FWIW, the blockchain itself isn't new technology at all. Satoshi's contribution to the state of the art was to figure out how to make the tech work without central authority or identity. What you're doing goes in the exact opposite direction, and is better done in centralized systems; Bitcoin has no advantage over those much faster, cheaper, and more scalable systems other than freedom from regulation.

If you want to work further on this technology, I can pass your name onto companies working in this space. Personally I'm rather dubious about taking on those clients for hopefully obvious reasons...
16  Bitcoin / Development & Technical Discussion / Re: Coinjoin improvement..? on: April 24, 2015, 03:47:36 PM
EDIT:
Found the method used to detect coinjoin txs:
Quote
We defined this pattern as any transaction having more than five inputs and more than five outputs, and looked at how many transactions matched this pattern (which is admittedly only roughly correlated with coinjoins, but as coinjoins are indistinguishable from other transactions we cannot do better than an approximation).
TBH, that sounds like a terrible heuristic to detect coinjoin txs  Roll Eyes

Agreed - very few Darkwallet Coinjoin's will be detected by that huristic. I just checked my wallet and only about %10 of the Coinjoins had more than four outputs. The usual transaction pattern in Darkwallet is for there to be four outputs - sender destination, sender change, mixer duplicated amount, mixer change - and two to four inputs.
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [SOFTWARE SALE LIVE] FACTOM - Introducing Honesty to Record-Keeping on: April 21, 2015, 03:51:10 AM
Proof of Existence is the proof of the positive, which can certainly be done in this fashion.  The problem is that it doesn't prove the negative.  Factom allows you to create a Factom Chain where you can not only prove the existence of everything in that chain, but prove no other entries are in the chain.

Peter Todd is working on  a project called Proof Chains (https://github.com/proofchains) that allows you to create a chain of entries in Bitcoin that duplicates Factom's features.  The downside is that your data 1) is directly in the Bitcoin blockchain,

Incorrect for most use-cases; proofchains itself doesn't have any data publishing tech yet anyway.

2) requires Bitcoin's transaction fees (more expensive), 

Often correct, though there are ways to mitigate this issue. Of course, for many applications even $1/proof fees are so cheap as to be effectively free. (e.g. land title registrations)

3) is subject to censorship (by those that don't like this stuff in Bitcoin),

100% incorrect in most use-cases. For the few applications that do need to publish data directly there are many techniques available to make censorship very difficult.

4) requires users to hold the whole Blockchain for their proofs,

Very incorrect. Proofchains techniques work just fine with SPV.

5) is subject to Bitcoin confirmation times,

Correct.

6) requires users to manage and hold Bitcoin wallets to write their data, and

True, although outsourcing the holding of Bitcoins to third parties is pretty easy, and can be done without trusting those third parties.

7) has no means to incentivize the development and support of the code.

Not as exciting as crowdsales, but going to clients and telling them "Hey! I can solve this problem you have." still works reasonable well, provided there actually exists a problem to solve.

Factom seeks to address these and other issues.  It turns out that building a censorship resistant layer over bitcoin to write arbitrary data is just harder than it looks.

It is, which is why I've focused on solving specific problems and building low-level libraries to help solve such problems.
18  Bitcoin / Development & Technical Discussion / Re: Salvaging refund protocols from malleability attacks with P2SH on: April 20, 2015, 08:43:18 PM

We change the protocol so that the escrow payment is to P2SH(2 of 2 Alice2, Bob2) and Alice2 and Bob2 are new keys that they've never used elsewhere and Bob does not know Alice2.

Alice computes the refund but instead of telling bob the refund transactions, she tells Bob only the hash value she wants signed with Bob2.


Is there a library that supports this?

Any Bitcoin library that gives you sufficiently low-level access to transaction signing will support this. For instance my own python-bitcoinlib lets you, as you can see in the P2SH signing example.
19  Bitcoin / Development & Technical Discussion / Re: Storing large data in blockchain on: April 15, 2015, 01:44:54 AM
It is not too difficult to create a tool to get data as a plain text from these transactions (but I do not have interest to do it)

Speaking of tools ... http://bitcoinstrings.com/blk00251.txt Wink

Also here: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py
20  Bitcoin / Development & Technical Discussion / Re: Pruning OP_RETURNs with illegal content on: February 10, 2015, 12:01:24 AM
You can much more easily publish data via the blockchain w/o OP_RETURN, and furthermore, you can easily put that data in to the UTXO set which all nodes *must* have if they are to maintain consensus.

Mike Hearn suggested we adopt blacklists to solve this problem back when someone put the child porn sections of the hidden wiki into the UTXO set; no-one's come up with a better solution since. You can make publishing that data more expensive by a small linear factor - about 10x to 100x - but that's the best you can do.

The best solution to this problem is legal and political: the idea that you have to prevent every last trace of "illegal data" from getting into a public ledger is absurd.
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 ... 62 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!