|
Bitcoin - an idea worth spreading for.
|
|
|
|
The first one.
And yes, anyone can check an open source project what it does but:
1st: I had no idea if it was open source, I didn't research everything you information you have to offer on it but I didn't notice it
2nd: not everyone is a programmer and can read code
So my suggestion was just something to help you get a wider user base be more comfortable in using not, not some sort of an accusation or something..
You don't have to be able to read code. The fact that there are no posts of people in this thread claiming to have found malicious code in electrum should gain quite a bit of your trust. You must assume that there actually are people doing that, though. Of course it's not impossible that ThomasV could sneak something into some update release and it would go unnoticed for a while (once anyone notices, he could immediately transfer all the coins). I would assume it would be noticed pretty quickly and a big fat red post would appear here. Your suggestion of having a one-time audit done by someone trusted would not help against that either. |
|
|
|
We also still have 80.575 BTC of outstanding orders, so 33% of the portfolio is just BTC, and 31.81% of the portfolio is invested in companies that have either not paid a dividend yet, or pay monthly, so it was not included in this dividend.
Wow. Not bad at all. I expected less on the first payment. Good job! get that rest of the capital workin then :-D wouldnt it be more practical to just "forward" the dividens as they roll in sans the fees? that would might reveal information about holdings. |
|
|
|
We also still have 80.575 BTC of outstanding orders, so 33% of the portfolio is just BTC, and 31.81% of the portfolio is invested in companies that have either not paid a dividend yet, or pay monthly, so it was not included in this dividend.
Wow. Not bad at all. I expected less on the first payment. Good job! |
|
|
|
If you're a government, or a bank, trying to kill bitcoin, the way to kill interest in bitcoin is simple - kill the value of the coin. At $41M market cap, it wouldn't be hard to kill it with money, no need whatsoever for hash power. That's way too much work. No need to slow transactions, too much work again.
Acquire coins, dump 'em, tank the market. At the level of trillions vs. millions, it doesn't take much effort to do this. Do it a few times, and no one wants to hold that asset. Oh, and maybe stop allowing transactions related to it, but that's probably secondary.
And how exactly would you go about acquiring the necessary sizeable pile of coins? |
|
|
|
|
you're looking for people that "have an idea of electronic music" or people that produce electronic music?
|
|
|
|
thanks for all your info, mila just repeat the create step with another ticker
and as time of ipo choose yesterday or 1 minute from now
the script that issues shares runs every 2 minutes so it might take a while
your ipo seems like waiting for midnight ...
I entered "0.1 hours from now" for ipo time |
|
|
|
|
guys, sorry I'm late to the party, maybe too late.
I created and account (worked this time) and tried to create a issue (PROFIT). I played around but can't seem to even do the most basic things like enter orders.
Is there any documentation (guess not, right?)
Is there a place to talk? checked #glbse, noones talking.
|
|
|
|
Considering ngzhang had about 100 FPGAs in his room mining at about 380 gigahash, it is entirely possible someone is just mining with FPGAs on their own. We've said his name numerous times, but he's not Beetlejuice. We all know he has the early money and funding to do it and the technical expertise to make it work.
Why isn't he including transactions? Because he doesn't have to. This happened in Bitcoin's history once before.
It's ArtForz, folks. Move along.
"because he doesn't have to" is not a reason. He doesn't have to mine either, yet he does. I'm not ruling him out, but I find it suspicious that there are no tx. Someone else with the FPGA/ASIC power? More likely. It could really be FPGA board testing, as was suggested. Maybe someone doing this stealthily without the higher-ups knowledge so he tries to keep a low profile network-wise or the testbed-hardware doesn't have the resources for full blockchain or is booted from a read-only usb stick or something... |
|
|
|
I'm planning to just have one chronological view of all transactions, and where fee's would be tied to the transactions they're on. For the time being it's all split into different sections.
A good idea! EDIT: can you drop a line here when signup should work so I can help testing? |
|
|
|
Hey guys, most will laugh at this, but I turn off my fpga-miner at night because it's just too noisy. WHAT? you will say, but the x5000 original fan is this tiny screeching trouble-maker:  Now, I'm not only jealous towards all the x6500-owners for the hashing-power, but also because of their much better cooling solutions (kudos for the improvements). So I thought, fuck it, let's cool like the big boys and try this:  Notice the yellow cable-binders I used? These also add little feet as a side-effect (sadly there are no holes in x5000 pcb). As for the cooling-effect, well, it didn't work. The cooling block got hotter than with the old fan, very hot to the touch, after 10 mins. So I tried this:  and this works like a charm. The cooling block is actually "cold" (well, at least not "warm") to the touch, while it was "hot" before with the small factory fan. it's very silent (not much airflow at all). Now I can mine at night again ^^ |
|
|
|
Feels like you're ganging up on me, anyway I'll drop the dividend fee for the time being, if at a later time I want to reintroduce it we'll have a discussion first. I apologize. I was merely acting to protect the income I have promised my shareholders. Thank you Nefario, for your continued efforts. We all appreciate it. Coola boola, could you explain to this chap why split fees wont really work on a stock exchange (or explain to me why they will). I can see that you can clearly not withhold x% of the shares from the buyer, but why withhold 0.5% from the money passed to the seller (as you plan to do now) and simply deduct the other 0.5% from the buyers balance? Of course this would mean having to check the buyers balance for sufficient funds for the fee and that might complicate things a lot. On another note I think it really doesn't matter who pays the fee. Prices will just reflect that: as a seller, I know I pay 1% fee so I can make my price a little higher to adjust for that and "make the buyer pay the fee" (or half the fee or whatever, the market will do that for us). So my suggestion to nefario is: do it as planned, have the seller pay the full fee. |
|
|
|
Hi, tried to sign up on dev.glbe.com got an error, has to do with csrf. I save the error page: http://pastebin.com/yQ2bmnGx (too big for a screenshot) |
|
|
|
|
deepceleron, when you argue higher transaction fees, you sound like a greedy banker, making up all this crap to support your bonus payments.
just wait for the block reward to drop, fees will effectively double at that point.
|
|
|
|
We better make bitcoin as solid as possible before we really depend on it. People like Luke-Jr and ArtForz attacking alt-chains is part of this hardening-process. I'm interested in knowing the details of what happened with the attacking of alt-chains by Luke-jr and ArtForz, can you please point me to the right threads, if this is has been already discussed elsewhere? I didn't dig very deep, but here are some pointers for you: maybe this helps you to research it a little further if you like. |
|
|
|
Yeah, I now see Luke's intentions are fine. The solution is now to make a Bitcoin client with TOR built-in.
TOR doesn't need to be built-in. use "torify" or whatever. Why would bitcoin tie itself to a single privacy solution that can easily be outsourced? |
|
|
|
It seems I am overreacting. I truly understand what this actually is now but I am still skeptical.
This is a reaction to people wanting to find out who is producing the blocks without transactions ( https://bitcointalk.org/index.php?topic=67634). The node inherently knows where the blocks it receives come from. This patch is merely logging this info to debug.log. I made a similar one: http://pastebin.com/EgJAGnSj. This in itself I find not worrying. Of course one could connect a node to as many other nodes as possible and find out where a block/tx is originating from (the node first broadcasting it). This is already done by many (for example blockchain.info, bitcoinwatch.com do this to determine source of blocks for statistics) So yes, this might be a privacy-problem for some, albeit a small one (even if you're identified as the originator of some transaction, it's still unknown who the recipient is. Looking at a transaction, I cannot tell wether or not it goes to SR, for example). If you want to mask yourself as the originator of a block/tx you will have to resort to established IP-hiding measures (use proxy, i2p, tor). If I was, for example, the linode-thief, I would certainly do this. EDIT: I dont assume luke-jr wants this pull-request pulled into bitcoin. He's just using github as a conventient place to publish his patch to interested parties. |
|
|
|
Can't we easily solve this problem by convincing all honest nodes to reject 1tx blocks?
If this happens, the MM has to include at least one other tx to make any BTC at all. This will force him to engineer some sort of solution to verifying transactions (supposedly he isn't verifying now due to the cost of managing the blockchain). Either he will give up or he'll start including transactions.
thoughts?
What happens when no one sends a transaction, and there are none to include? Why couldn't the miner include 1 or 2 txns of his own in each block to pad it out to the required minimum? TL;DR, NO. Won't work. If you're going this route, as a node, you could look at the number of transactions (maybe add up their fees) you have collected yourself from the network and require a certain percentage of that to be included in order for a given block to be accepted by you, say 20% for example. So if you have accumulated 20 transactions, a block would have to include at least 4 of these in order for you to accept it. This would guarantee the block to contain at least some fresh transactions. Someone can connect to your node from different IPs, fill your memory pool with TXes and then you'll orphan yourself. Of course it's not that easy, but I don't like this way. Also sometimes bitcoin just have to create 1tx blocks even when there are lots of TXes. I don't like it either and I'm not suggesting to do this, I was merely improving a bit on the initial "idea". I understand the "orphan attack on a node", but please explain why "sometimes bitcoin just have to create 1tx blocks even when there are lots of TXes" ? Right after startup? |
|
|
|
here's a patch to bitcoind (git) that logs the ip-addresses from which 1-tx-blocks are received: http://pastebin.com/EgJAGnSjso in case someone sees his own IP in this thread, you could go ahead and identify the origin  |
|
|
|
|
Show Posts
