Bitcoin Forum
May 03, 2024, 09:51:20 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 [356] 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 ... 429 »
7101  Bitcoin / Development & Technical Discussion / Re: [proposal] [Stratum] Overlay network protocol over Bitcoin on: January 02, 2012, 02:39:31 AM
watching

7102  Bitcoin / Project Development / Re: Create a game that accepts Bitcoin for currency on: December 31, 2011, 09:24:32 PM
... anybody here read the latest by Neal Stephenson .... REAMDE

MMORPG game currency and economy is a central theme ... crypto, gold, etc. Lots of ideas in there.

http://en.wikipedia.org/wiki/Reamde
7103  Bitcoin / Project Development / Re: [CLOSED] 2 BTC for suggesting a name of an overlay network on top of Bitcoin on: December 31, 2011, 08:50:16 PM
There are the winners .......


and then there are the Losers.



Edit: slush I'm happy to send you back the 2 btc if you think someone can find a better name.
7104  Bitcoin / Project Development / Re: [contest] 2 BTC for suggesting a name of an overlay network on top of Bitcoin on: December 30, 2011, 06:47:32 PM
I'm not sure if the name should have anything to do with "electrum." At first I thought it should, but this proposal could be implemented by any exit node for thin clients.

It is unavoidably related anyway by the technical task being performed, thin-client/bitcoin-server federation. Fortunately, they happen to share the same suffix, um.

It could be nice to have any other thin clients identify with Stratum in a similar manner and hat-tip to the founding idea of Electrum, that now becomes the special case of the wider family, but it is not necessary, eg. Aurum, Hum, Drum, Plum, Rum, etc.  Also related layers can easily be identified superstratum, substratum, etc.

Slush : PM coming your way Smiley Hope you have fun with your new layer, Stratum. I wonder how much overlap there might be here with the OpenTransactions client-server federation crypto-currency transaction s/ware that is already built?
7105  Bitcoin / Project Development / Re: [contest] 2 BTC for suggesting a name of an overlay network on top of Bitcoin on: December 28, 2011, 08:54:51 PM
Stratum

(new layer)

or if it really is an unneccessary layer, "Administratum"  Wink

Edit: also reserving some stratum derivatives

Superstratum 

(in latin literally overlay or 'the layer above/over /'on top of')

Suprastratum

7106  Bitcoin / Project Development / Re: [Alpha testing] Open Transactions server on: December 24, 2011, 01:11:40 AM

Happy Christmas!

 Wink
7107  Bitcoin / Electrum / Re: [ANNOUNCE] Electrum - a new thin client on: December 24, 2011, 12:41:41 AM
Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.

that is correct. perhaps I should add a big fat warning during the import command?
in any case, I think that this command should not be available from the gui, in order to make sure that it is not used too easily.

Thanks. A big, fat warning would be good.

I knew it would be as much the case but wanted to make it clear to those who are unaware ... if it was left 'unsaid' who knows what grief may come back on Electrum for no good reason, except that it had an extra feature that was misunderstood.
7108  Bitcoin / Electrum / Re: [ANNOUNCE] Electrum - a new thin client on: December 22, 2011, 12:45:43 AM
I just uploaded version 0.35 to the website.

Changelog:
* New 'import' command to add extra keypairs to your wallet. Example:
Code:
python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng
Note that you can export your keypairs in the same format using:
Code:
python electrum.py addresses -k


Can you confirm if the following is correct?

The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.
7109  Bitcoin / Electrum / Re: [ANNOUNCE] Electrum - a new thin client on: December 17, 2011, 09:55:16 PM
2112
Quote
The replies from slush and SgtSpike show that they simply don't understand generally accepted accounting principles.

Neither it seems do wall st. banks or the federal reserve. As I recall they suspended GAAP to weather the financial panic in 2008, as far as I'm aware those "toxic assets" that were exempted from GAAP rules are still stinking up the joint underneath a TARP somewhere, still exempt from GAAP.

Perhaps channel your anger in that direction? (i.e. the destroyers, not the creators)
7110  Bitcoin / Bitcoin Discussion / Re: People with Backdoor-Control of Banking Servers Blocking Bitcoin Exchanges on: December 13, 2011, 09:01:14 AM
Not as far-fetched as you might think.

Most all inter-country electronic bank transfers in the world goes through essentially the ONE global clearing/settlement system.

It makes it pretty easy to do what he's suggesting. Also makes it pretty easy for the whole thing to come unstuck and send us all to monetary hell. Oh, the joys of a centralised system.
7111  Bitcoin / Bitcoin Discussion / Re: Secure bitcoin private key storage for your pocket on: December 13, 2011, 08:45:05 AM
Looks cool. Lock has at least one use case I can think of but do not want to state here.

Wonder if you could swallow the thing in a hurry? .... nice and round for the exit at least.
7112  Bitcoin / Project Development / Re: BitSafe fork with Electrum included on: December 13, 2011, 08:17:12 AM
earmark.
7113  Bitcoin / Development & Technical Discussion / Re: Elliptic curve math question on: December 07, 2011, 12:50:23 PM
hmmmmm.
7114  Bitcoin / Bitcoin Discussion / Re: Bitcoin the enabler - Truly Autonomous Software Agents roaming the net on: December 07, 2011, 11:14:48 AM
It could purchase the resources it needs to survive (hosting/cpu/memory) and sell services to other agents or to humans.

It can survive indefinitely doing nothing but sitting on a large enough chunk of bitcoin as long as there is general economic growth. It just has to spend less to keep itself alive than it earns in interest on the bitcoin appreciation.


Hey, if you can get enough of them out there in the wild and multiplying you could create some real demand for bitcoin .....
7115  Economy / Service Announcements / Re: [ANNOUNCE] Bitcoin Fog: Secure Bitcoin Anonymization on: December 06, 2011, 01:30:44 AM
watching.
7116  Bitcoin / Project Development / Re: [Private Alpha] Open Transactions server on: December 01, 2011, 10:54:09 AM
Watching this ...

doublec ... there is wiki at the github for OT server and Moneychanger also (the client)

https://github.com/FellowTraveler/Moneychanger/wiki
7117  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: November 17, 2011, 11:01:34 PM
What happens when the .bit domain gets officially used by ICANN? Has anyone thought about that?
Nothing? Since namecoin is a different dns system, the two can work together. Of course you need to tell your browser if the .bit address you are looking for is a namecoin one or a normal icann one.

That situation seems decidedly un-nothing-like to me, and awfully browser-centric.

As it currently stands, DNS resolver operators can add transparent support for the .bit space 'as if' it were the same as any other toplevel domain.
Scripts/email systems etc can then resolve .bit names without specific configuration.

The fact that ICANN may effectively yank this mode of operation out from under us (you can bet nearly all resolver operators will revert to resolving official ICANN names) is surely a risk which may make it hard to convince operators to support it in the first place.




Why would ICANN want to use .bit TLD in the first place ... see how much resistance they put up to extending beyond the limited set they began with. Adding in .bit for them would create more confusion than clarity. There is little upside for them to commandeer it at this stage. Why would they it is not like it is .com or .org ...
7118  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [announce] Namecoin - a distributed naming system based on Bitcoin on: November 17, 2011, 10:08:28 PM
You guys need to hurry up :

-rescan functionality still not working
-wallet encryption not working
-GUI nowhere to be found
-alternate clients without TX fees requirement ?

They will be open for help I'm sure.

If you were a paying customer it may be different .... but you are not.
7119  Bitcoin / Bitcoin Technical Support / Re: bitcoind + vidalia and potenially dangerous connections on: November 17, 2011, 10:02:57 PM
why on earth would you run your bitcoin wallet on tor, to me that's just asking some to hack you.

Actually almost the opposite is true.

Running an unproxied bitcoin always from the same static IP on the internet is like dropping your trousers in public. (Having an unencrypted wallet connected to such a node would be like bending over with trousers around ankles in public.)
7120  Bitcoin / Electrum / Re: [ANNOUNCE] Electrum - a new thin client on: November 17, 2011, 09:56:05 PM
Any plans to make that a https connection to a server for added privacy possibility (man listening in the middle)? I suppose connecting to a electrum server across tor would work just as well against that anyway.

Only if you're talking about a server which is a tor hidden service. Connections to hidden services are encrypted and authenticated, end-to-end. If only the client is using tor to connect to a normal server (public IP), then it's much worse, you must use ssl in this case, as otherwise the exit-node can do pretty much what he wants.

So, if the current client does not support ssl connections, do not put it behind Tor, unless you're accessing a hidden server.

Yes. But only connecting to trusted Electrum servers over plain text http seems to be a requirement for this system work as a default position no? Or is there some way that a client can figure out if the server (or interceptors) is not just spoofing an Electrum server for nefarious purposes?

A client behind tor to a trusted server removes traceability of transacting BTC addresses to originating wallet IP, since they could have come from anywhere on the tor network. An end-to-end ssl connection is obviously better but allows the server to know the IP of the transacting wallet addresses.

The ultimate would be a federation of trusted Electrum tor hidden servers, I agree. No way for server (or interceptors) to link transacting Electrum client wallet BTC addresses with originating IPs. (Of course there are many other ways to do this besides, drive-by public wifi, etc)
Pages: « 1 ... 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 [356] 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 ... 429 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!